Audit and improve web accessibility following WCAG 2.1 guidelines. Use when asked to "improve accessibility", "a11y audit", "WCAG compliance", "screen reader support", "keyboard navigation", or "make accessible". Do NOT use for SEO (use seo), performance (use core-web-vitals), or comprehensive site audits covering multiple areas (use web-quality-audit).
81
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./packages/skills-catalog/skills/(quality)/web-accessibility/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong skill description with excellent trigger term coverage and completeness. The explicit 'Do NOT use' clauses for related but distinct skills are a notable strength that reduces conflict risk. The main weakness is that the capability description could be more specific about concrete actions beyond 'audit and improve'.
Suggestions
Add more specific concrete actions to the capability statement, e.g., 'Audit and improve web accessibility following WCAG 2.1 guidelines, including checking color contrast, adding ARIA labels, fixing alt text, and ensuring proper heading hierarchy.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (web accessibility) and a key standard (WCAG 2.1), but the actions are somewhat general ('audit and improve'). It doesn't list multiple specific concrete actions like checking color contrast, adding ARIA labels, fixing alt text, etc. | 2 / 3 |
Completeness | Clearly answers both 'what' (audit and improve web accessibility following WCAG 2.1) and 'when' (explicit 'Use when' clause with multiple trigger phrases). Also includes explicit 'Do NOT use' guidance for disambiguation, which goes above and beyond. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms: 'improve accessibility', 'a11y audit', 'WCAG compliance', 'screen reader support', 'keyboard navigation', 'make accessible'. These are terms users would naturally use when requesting accessibility help. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with explicit boundary-setting via 'Do NOT use' clauses that differentiate it from SEO, performance, and comprehensive audit skills. The accessibility/a11y/WCAG niche is clearly carved out with minimal overlap risk. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a thorough accessibility reference with excellent, actionable code examples covering all WCAG 2.1 principles. Its main weaknesses are its length (could be split into an overview + detailed references) and the lack of an explicit audit workflow with validation checkpoints. The introductory tables explaining POUR principles and conformance levels add little value for Claude and could be trimmed.
Suggestions
Add an explicit audit workflow at the top (e.g., '1. Run Lighthouse/axe → 2. Review critical issues → 3. Fix and re-test → 4. Manual keyboard/screen reader test → 5. Verify all critical issues resolved') with validation gates between steps.
Move detailed code examples for each POUR principle into separate reference files (e.g., PERCEIVABLE.md, OPERABLE.md) and keep SKILL.md as a concise overview with links.
Remove the POUR principles table and conformance levels table — Claude already knows these concepts. Replace with a one-line note like 'Target WCAG 2.1 AA conformance' and jump straight into actionable patterns.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite comprehensive at ~350 lines and includes some content Claude already knows (WCAG principles table, conformance levels explanation, basic HTML semantics). The POUR principles table and conformance levels are general knowledge that don't add actionable value. However, the code examples themselves are lean and well-structured. | 2 / 3 |
Actionability | Excellent actionability with fully executable HTML, CSS, and JavaScript examples throughout. Every section provides concrete before/after code patterns (❌/✅), specific CSS values for contrast ratios, complete modal focus management code, and ready-to-use testing commands. | 3 / 3 |
Workflow Clarity | The testing checklist at the end provides a clear sequence, and the 'common issues by impact' section prioritizes work well. However, there's no explicit audit workflow (e.g., 'run automated tools first → review results → fix critical issues → manual test → re-run'). For an audit skill, a step-by-step process with validation checkpoints between automated and manual testing phases would strengthen this significantly. | 2 / 3 |
Progressive Disclosure | The content is well-organized with clear section headers following the POUR framework, but it's a monolithic document that could benefit from splitting detailed code examples into separate reference files. The references section at the end links to external resources and one related skill, but the inline content is very long for a SKILL.md overview. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (532 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
81e7e0d
Table of Contents
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.