要点
Audit and improve web accessibility following WCAG 2.2 guidelines and best practices.
- Covers all four WCAG principles (Perceivable, Operable, Understandable, Robust) with conformance levels A, AA, and AAA
- Includes code examples for text alternatives, color contrast, keyboard navigation, focus management, form labels, error handling, and ARIA usage
- Provides testing checklist with automated tools (Lighthouse, axe-core) and manual testing procedures for keyboard, screen reader, zoom, and motion preferences
- Highlights critical issues (missing labels, alt text, contrast, keyboard traps) and new WCAG 2.2 criteria like target size, focus visibility, dragging alternatives, and accessible authentication
SKILL.md
Accessibility (a11y)
Comprehensive accessibility guidelines based on WCAG 2.2 and Lighthouse accessibility audits. Goal: make content usable by everyone, including people with disabilities.
Evidence-led audit workflow
When a rendered page is available:
- Run a live Lighthouse Accessibility audit when that capability is available; with Chrome DevTools MCP, use
lighthouse_audit. Use mobile navigation mode for a general public page or snapshot mode when reloading would lose authenticated or user-created state. - Use failed audit nodes to localize the relevant component or template instead of searching the whole repository for generic patterns.
- Inspect a rendered accessibility-tree snapshot for names, roles, states, landmarks, and heading structure; with Chrome DevTools MCP, use
take_snapshot. Exercise the affected flow with the keyboard. - Fix the source, then re-run the same audit and manual interaction.
If the live tools are unavailable, use Lighthouse CLI or axe for automated coverage and complete the same manual checks. Automated tools detect only a subset of accessibility barriers: a score of 100 is not WCAG conformance, and a low score does not replace issue-level evidence.