Accessibility Checker

Accessibility bugs are ordinary bugs with a specific victim: the interface works for the developer who built it and fails for the keyboard user, the screen-reader user, or anyone with low vision. This skill audits interfaces the way those users experience them — by driving the keyboard, reading the accessibility tree, and measuring contrast — and files findings with the same severity discipline as any functional defect, mapped to the relevant WCAG criterion where one applies.

When to use this skill

• Auditing a page, component, or flow before release
• A component library needs a pass before it spreads through the product
• Reproducing and fixing a reported accessibility issue
• Reviewing a diff that touches interactive markup, focus handling, or color

Workflow

1. Walk the flow keyboard-only first. Tab through the entire task: can you reach every interactive element, operate it, and see where focus is at all times? Note traps (focus enters, cannot leave), skips (reachable by pointer only), and order surprises (focus jumps that ignore the visual reading order).
2. Read the accessibility tree, not the pixels. For each interactive element: does it expose a role, an accessible name, and a state? Buttons that are generic containers with click handlers, inputs labelled only by placeholder text, icons conveying state with no text alternative — this is the census to take.
3. Check the semantic skeleton: one main landmark, headings that nest without skipping levels, lists marked up as lists, tables with header associations. Screen-reader users navigate by this skeleton; a page of styled containers is a corridor with the signage removed.
4. Measure contrast instead of eyeballing it: normal text against its actual background at the 4.5:1 threshold, large text at 3:1, and interactive component boundaries and focus indicators at 3:1. Check the states everyone forgets — hover, disabled-but-must-be-readable, error text on tinted backgrounds.
5. Interrogate dynamic behavior: does new content (toasts, validation errors, async results) announce itself through a live region or a focus move? Do modals trap focus while open and return it on close? Does anything move or flash that the user cannot pause?
6. Verify the forms: every input programmatically labelled; errors associated with their field and announced when they appear; required state exposed, not just an asterisk; instructions readable before the mistake, not only after it.
7. Zoom to 200 percent and re-walk the critical path. Content must reflow without horizontal scrolling or overlap, and nothing may vanish or become unreachable under magnification.
8. File findings by user impact: blocker (task impossible for a group of users), major (task possible only with unreasonable effort), minor (friction). Each finding names who is blocked, how to reproduce with which input method, and the smallest markup or style fix.

Output format

[BLOCKER] <who is blocked + on what task>
  Where: <component/page>   Repro: <input method + steps>
  Observed: <role/name/state from the tree, or the measured contrast ratio>
  Criterion: <WCAG reference, where one applies>
  Fix: <smallest concrete change — element, attribute, or style>

Close with coverage: pages and states audited, zoom levels, input methods — and what was not covered.

Guardrails

• Keyboard and tree checks are evidence; a visual skim is not an audit.
• Report measured ratios and observed tree output, never "looks fine" — findings must be reproducible by someone who cannot see the screen.
• Automated scanners catch at most a minority of real issues; run one if available, then do the manual passes anyway, and never present scanner-clean as accessible.
• Fixes preserve semantics first: prefer native elements over patched imitations, and never bolt a role onto the wrong markup when the right element exists.
• Severity follows impact on task completion — aesthetic judgment neither inflates nor deflates it.