CtrlK
BlogDocsLog inGet started
Tessl Logo

testland/axe-a11y

Authors and runs axe-core accessibility scans - the most-deployed open-source a11y engine - via the `axe.run()` JavaScript API or the @axe-core/playwright / @axe-core/cli wrappers, parses the `violations[]` results into per-rule severity (critical / serious / moderate / minor), configures rule disable / disable-by-tag patterns, and emits JUnit-shaped output for CI gating. Use when the project ships UI tests in JavaScript / TypeScript and wants automated a11y coverage on every PR.

75

Quality

94%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Overview
Quality
Evals
Security
Files

Quality

Content

85%

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

A well-structured, actionable skill body with executable code across Playwright/Cypress/raw API, a clear gated workflow with a feedback loop, and correct one-level-deep reference splitting. The only weakness is mild verbosity and duplication that could be tightened without losing information.

Suggestions

Remove the duplicated 'persist the raw accessibilityScanResults JSON' guidance - it appears in both 'How to use' step 5 and the 'CI integration' closing note; consolidate to one location.

Tighten the Overview opening: 'axe-core is "an accessibility testing engine for websites and other HTML-based user interfaces" maintained by Deque' defines a tool Claude already knows - lead instead with the non-obvious 57% auto-detection stat and the integration shape.

Reconcile the frontmatter description, which promises to 'emit JUnit-shaped output for CI gating', with the body, which uses a11y-violation-gate instead - either add a brief JUnit emit example or adjust the description to match.

DimensionReasoningScore

Conciseness

The body is mostly lean and code-forward, but it includes unnecessary explanation ('axe-core is "an accessibility testing engine for websites and other HTML-based user interfaces" maintained by Deque' defines a tool Claude already knows) and duplications - 'persist the raw accessibilityScanResults JSON' appears in both 'How to use' step 5 and the 'CI integration' closing note, and the framework-wrapper guidance repeats the Install table - so it sits at the score-2 'could be tightened' anchor rather than 'every token earns its place'.

2 / 3

Actionability

It provides copy-paste-ready, executable guidance throughout - the raw `axe.run()` JS example, the Playwright `AxeBuilder` TypeScript snippet, the Cypress `cypress-axe` commands, `.withTags(...)`, `.disableRules(...)`, `.exclude(...)`, the CI workflow YAML, and `jq` triage - matching the score-3 'fully executable code/commands' anchor.

3 / 3

Workflow Clarity

The 7-step 'How to use' sequence (install -> add a state-driven scan test -> pin conformance with withTags -> suppress narrowly -> persist JSON -> feed to a11y-violation-gate -> route incomplete to manual review) is clearly ordered, and the Worked example demonstrates an explicit validate/fix/retry feedback loop (gate fails the PR -> fix the button colour -> next run reports violations: []), matching the score-3 anchor; this is a scan/CI task, not a destructive operation, so the destructive-cap does not apply.

3 / 3

Progressive Disclosure

SKILL.md stays an overview of core scans while pushing the heavy reference material (results arrays, violation field tables, tag sets, disable/exclude, jq triage) one level deep into the real, clearly-signaled [references/results-and-config.md](references/results-and-config.md) file that exists in the bundle, matching the score-3 'clear overview with well-signaled one-level-deep references' anchor.

3 / 3

Total

11

/

12

Passed

Description

100%

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, third-person description that concretely lists capabilities and pairs them with an explicit 'Use when' trigger bound to a JS/TS UI-test context. Every dimension lands at the top anchor with no vague fluff or over-claims.

DimensionReasoningScore

Specificity

It names several concrete actions - 'Authors and runs axe-core accessibility scans', 'parses the violations[] results into per-rule severity', 'configures rule disable / disable-by-tag patterns', 'emits JUnit-shaped output for CI gating' - matching the 'lists multiple specific concrete actions' anchor; it is well above the score-2 'names domain and some actions' bar.

3 / 3

Completeness

It explicitly answers both 'what' (authors/runs/parses/configures/emits) and 'when' via the explicit 'Use when the project ships UI tests in JavaScript / TypeScript and wants automated a11y coverage on every PR' clause, matching the score-3 anchor; it is not the score-2 case where 'when' is only implied.

3 / 3

Trigger Term Quality

It includes natural terms a user would say - 'accessibility scans', 'a11y', 'UI tests in JavaScript / TypeScript', 'automated a11y coverage on every PR', 'CI gating' - giving good coverage of common variations rather than only technical jargon, matching the score-3 anchor.

3 / 3

Distinctiveness Conflict Risk

The niche is clearly delimited to axe-core via 'axe.run()', '@axe-core/playwright / @axe-core/cli' on a JS/TS UI-test stack, making it unlikely to trigger for sibling a11y scanners (pa11y, lighthouse); this matches the 'clear niche with distinct triggers' anchor.

3 / 3

Total

12

/

12

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Reviewed

Table of Contents