Check accessibility properly, with exact code fixes.

(What it does)

A deep accessibility audit. /crisp-a11y checks a component or screen against every relevant success criterion in WCAG 2.2 AA, the widely used web accessibility standard, across its four principles: perceivable, operable, understandable, and robust. Each criterion is marked pass, fail, or not applicable. Every failure gets a clear description, a P0–P3 severity, and a code fix precise enough to implement without guesswork.

It goes four times deeper than the accessibility checklist in /handoff, calculates real contrast ratios when you provide your colour values, and ends by writing an a11y-checklist.md file the team can commit.

(When to use it)

Use it when you need evidence of accessibility, not reassurance:

• A pre-launch compliance check on a key flow or component
• Someone has reported a keyboard or screen reader problem and you need the full picture
• Reviewing a design system component that every screen will inherit
• The /handoff checklist raised questions that need answers criterion by criterion

(What you get)

• WCAG 2.2 AA scorecard
• Exact code fixes, not vague advice
• a11y-checklist.md
• Problems rated P0–P3 by severity

(Example output)

Illustrative example only. This is not a real audit.

(Native HTML before ARIA)

The audit's standing rule: use native HTML before adding ARIA (extra attributes that describe elements to assistive technology). A native button works with the keyboard, takes focus, and is announced correctly with no extra code. A div with role="button" needs tabindex, keyboard handlers, and ARIA to copy what the browser gives you for free. Any div or span acting as a control is flagged, and the fix is almost always the correct native element, not more ARIA.

(Common questions)

(Related skills)