CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/axe-a11y

Automated accessibility scanning across the five engines - axe-core (primary), pa11y, Lighthouse a11y, WAVE, and IBM Equal Access. Authors and runs axe-core scans via the `axe.run()` JavaScript API or the @axe-core/playwright / @axe-core/cli wrappers, parses `violations[]` into per-rule severity, configures rule disable / disable-by-tag patterns, and emits CI-gateable output; references/ carry the pa11y CLI (htmlcs + axe runners), Lighthouse CI `categories:accessibility` assertions, the WAVE API / overlay, and IBM Equal Access (Section 508) with their verified CLI / API / config. Use for any automated a11y scanner setup - axe-core for JS/TS UI test suites on every PR, and the references for CLI-only, Lighthouse-pipeline, WebAIM-branded, or Section 508 scanning.

72

Quality

91%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Overview
Quality
Evals
Security
Files

Quality

Content

86%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A high-quality body: executable code, complete CI wiring, a worked example with a feedback loop, and clean one-level-deep reference routing verified against the actual bundle. Remaining polish is trimming minor boilerplate and making the validation checkpoint less dependent on the external gate skill.

Suggestions

Trim the raw `axe.run()` example to the essential call (drop the spelled-out .then/.catch handling) and state the ~57% coverage figure once, in Limitations, to tighten conciseness.

Add a one-line inline validation checkpoint (e.g. how to confirm the gate consumed the JSON correctly) so the workflow's validation step doesn't depend entirely on the external a11y-violation-gate skill.

Give the Cypress path the same `.withTags([...])` configuration example as Playwright so both framework integrations are equally actionable.

DimensionReasoningScore

Conciseness

Mostly lean — dense tables for scanners, packages, and anti-patterns, with code kept minimal. Minor trimmable boilerplate: the raw `axe.run()` example spells out `.then`/`.catch` promise handling Claude already knows, and the '~57% of WCAG issues' figure appears in both Overview and Limitations. Not 5: a few tokens don't earn their place; not 3: there is no padded explanatory section.

4 / 5

Actionability

Copy-paste-ready guidance throughout: 'npm install --save-dev axe-core', a complete Playwright test with `.withTags(['wcag2a','wcag2aa','wcag22aa'])`, Cypress commands, a full GitHub Actions workflow YAML, and executable jq triage commands demonstrated on real output ('serious: color-contrast'). The common cases (install, scan, configure, gate in CI) are all covered with concrete code.

5 / 5

Workflow Clarity

The 'How to use' section gives a clearly sequenced seven-step workflow with concrete commands, and the worked example demonstrates an explicit feedback loop (gate fails → fix button color → next run reports `violations: []`). Not 5: validation is delegated to the external `a11y-violation-gate` skill rather than an inline checkpoint, and the Cypress path is thinner than the Playwright one.

4 / 5

Progressive Disclosure

The body stays an overview-plus-core-integration document; the four alternative scanners (pa11y, Lighthouse a11y, WAVE, IBM Equal Access) and the results/tag/config detail are split into references that all exist, are one level deep, and are clearly signaled via the routing table and the References section. Matches the 'clear overview with well-signaled one-level-deep references' anchor.

5 / 5

Total

18

/

20

Passed

Description

92%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description: concrete, third-person action coverage across five engines with an explicit, well-differentiated 'Use for...' clause covering per-engine triggers. The only gap is a handful of natural synonyms (e.g. WCAG compliance, accessibility audit) in the trigger vocabulary.

DimensionReasoningScore

Specificity

Lists multiple concrete actions in third person — 'Authors and runs axe-core scans via the `axe.run()` JavaScript API', 'parses `violations[]` into per-rule severity', 'configures rule disable / disable-by-tag patterns', 'emits CI-gateable output' — with comprehensive coverage across all five engines. Fits the 'multiple specific concrete actions; comprehensive coverage' anchor; nothing is left generic.

5 / 5

Completeness

Explicitly answers both: what — running scans via axe.run() and the @axe-core/playwright / @axe-core/cli wrappers, parsing violations into per-rule severity, configuring disable/disable-by-tag, emitting CI-gateable output; and when — 'Use for any automated a11y scanner setup - axe-core for JS/TS UI test suites on every PR, and the references for CLI-only, Lighthouse-pipeline, WebAIM-branded, or Section 508 scanning.' Matches the top anchor with concrete trigger phrases.

5 / 5

Trigger Term Quality

Includes natural phrases users would say — 'accessibility scanning', 'automated a11y scanner setup', 'axe-core for JS/TS UI test suites on every PR', 'Section 508' — plus engine names (pa11y, Lighthouse, WAVE). Not 5: common variations such as 'WCAG compliance', 'accessibility audit', or '508 compliance' are absent, so coverage is good but not comprehensive.

4 / 5

Distinctiveness Conflict Risk

Occupies a clear niche (automated a11y scanning across five named engines) with per-engine routing guidance that separates axe-core integration from CLI/Lighthouse/WAVE/Section-508 use cases, minimizing risk of triggering the wrong skill. Not 4: the routing makes overlap with related skills (e.g. manual screen-reader testing, CI gating) essentially nil.

5 / 5

Total

19

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents