accessibility-testing

Use when reviewing component libraries, page flows, or CI pipelines that need repeatable accessibility checks. Automated testing is strongest at catching structural and attribute-level issues; it does not replace keyboard, screen reader, and manual UX testing.

Quality

86%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

72%

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

The body is concise and well-structured with sound progressive disclosure, cleanly offloading detail to references/rule.md. It is weaker on actionability and workflow clarity because the body itself lacks executable examples and explicit validation checkpoints.

Suggestions

Add at least one inline, copy-paste-ready snippet (e.g., a minimal jest-axe or AxeBuilder test) so the body is actionable without forcing a file read.

Turn the Check/Fix sections into an explicit sequence with a validation checkpoint — e.g., "run the a11y suite; if violations appear, fix and re-run until <= 0 unexpected violations" — to add a validate-fix-retry loop.

Surface one concrete CI invocation command (e.g., `npm run test:a11y`) directly in the body so the CI/CD guidance is executable rather than descriptive.

Dimension	Reasoning	Score
Conciseness	The body is lean — a short framing line, a Quick Reference bullet list, and terse Check/Fix/Explain/Code Review sections — with no padding or explanation of concepts Claude already knows; not a 2 because there is no unnecessary explanation to tighten.	3 / 3
Actionability	Names concrete tools (jest-axe, @axe-core/playwright, cypress-axe) and specific rules ("color-contrast"), but the body contains no executable code or commands and several sections (Check/Fix/Explain) are directive verbs that describe rather than instruct with copy-paste-ready specifics; not a 3 because nothing in the body is copy-paste ready, and not a 1 because specific tool names and rule targets give real guidance.	2 / 3
Workflow Clarity	The Check/Fix/Explain/Code Review sections imply a loose sequence but there are no explicit validation checkpoints or a validate-fix-retry feedback loop in the body; not a 3 because checkpoints are absent rather than merely implicit, and not a 1 because a recognizable sequence of stages is present.	2 / 3
Progressive Disclosure	The body is a clear overview that explicitly signals a one-level-deep reference ("see references/rule.md"), and the referenced file genuinely holds the detailed content; not a 2 because the reference is clearly signaled and shallow rather than nested or poorly organized.	3 / 3
	Total	10 / 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.

The description is specific, trigger-rich, and complete, explicitly stating both what the skill does and when to use it with natural user-facing language. It is clearly niched to accessibility testing with low conflict risk.

Dimension	Reasoning	Score
Specificity	Enumerates concrete review targets — "reviewing component libraries, page flows, or CI pipelines that need repeatable accessibility checks" — naming multiple specific actions rather than vague language; not a 2 because it lists several distinct concrete targets rather than a single domain with partial actions.	3 / 3
Completeness	Explicitly answers both what (automated accessibility checks on components/flows/CI) and when via the "Use when..." clause; not a 2 because the trigger is explicit rather than merely implied.	3 / 3
Trigger Term Quality	Uses natural phrases users would say — "accessibility checks", "component libraries", "page flows", "CI pipelines" — giving good coverage of likely user phrasings; not a 2 because the keywords are natural and varied, not technical jargon or a single generic term.	3 / 3
Distinctiveness Conflict Risk	Clearly niched to accessibility testing with distinct triggers (component libraries, page flows, CI pipelines) unlikely to fire for unrelated skills; not a 2 because it is specific enough to avoid meaningful overlap with sibling skills.	3 / 3
	Total	12 / 12 Passed

Validation

93%

Warnings & errors only

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

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/accessibility-testing/SKILL.md
Commit: 48405aa

Reviewed: about 8 hours ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.