accessibility
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, clear 'Use when' and 'Do NOT use' clauses, and strong distinctiveness. The main weakness is that the capability description could be more specific about concrete actions beyond 'audit and improve'. Overall, it would perform very well in a multi-skill selection scenario.
Suggestions
Add more specific concrete actions to the capability statement, e.g., 'check color contrast, alt text, ARIA labels, focus management, semantic HTML' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (web accessibility) and a key standard (WCAG 2.1), but the actions are somewhat vague—'audit and improve' are high-level verbs without listing specific concrete actions like checking alt text, color contrast, ARIA labels, 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 helpful 'Do NOT use' guidance for disambiguation. | 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. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with explicit boundary-setting via the 'Do NOT use' clause that differentiates from SEO, performance, and comprehensive audit skills. The accessibility/a11y/WCAG niche is clearly carved out. | 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, highly actionable accessibility reference with excellent concrete code examples covering all WCAG 2.1 POUR principles. Its main weaknesses are length (could be more concise by removing explanatory tables Claude already knows) and lack of a clear audit workflow with validation/verification steps. The content would benefit from being split into a concise overview with references to detailed sub-files.
Suggestions
Add an explicit audit workflow at the top: 1) Run automated tools, 2) Review results, 3) Fix by priority, 4) Re-run tools to verify, 5) Manual testing checklist
Remove or drastically shorten the POUR principles table and conformance levels table - Claude already knows these concepts
Split detailed code examples (ARIA patterns, modal focus management, form handling) into separate reference files, keeping only the most critical patterns inline
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is quite comprehensive at ~350 lines and includes some explanatory content Claude already knows (WCAG principles table, conformance levels explanation). The POUR table and conformance levels section add little value for Claude. However, the code examples themselves are lean and well-structured with good ❌/✅ patterns. | 2 / 3 |
Actionability | Excellent actionability with fully executable HTML, CSS, and JavaScript examples throughout. Every guideline is paired with concrete, copy-paste ready code showing both incorrect and correct patterns. Testing commands are specific and runnable. | 3 / 3 |
Workflow Clarity | The testing checklist at the end provides a clear sequence, but there's no explicit audit workflow (e.g., 'run automated tools first, then manual checks, then fix by priority'). The 'Common issues by impact' section helps prioritize but lacks a feedback loop for verifying fixes after implementation. | 2 / 3 |
Progressive Disclosure | The content is a monolithic document with everything inline. At ~350 lines, the detailed ARIA patterns, modal focus management, and testing sections could be split into separate reference files. The references section at the bottom links to external resources but doesn't leverage internal file splitting for the extensive code examples. | 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 | |
- Repository
- tech-leads-club/agent-skills
- Commit
906a57d
- Reviewed
Table of Contents
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.