Browse the docs

Skills — Craft and build

/crisp-a11y

Accessibility, scored not skimmed.

Specialist extensionsuser-invoked

A deep accessibility audit. /crisp-a11y evaluates a component or screen against the applicable WCAG 2.2 AA success criteria — perceivable, operable, understandable, robust — and marks each pass, fail, or not applicable. Every failure gets an exact violation, a P0–P3 severity, and a code-level 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 token values, and finishes by writing a portable a11y-checklist.md the team can commit.

Reach for it when accessibility needs evidence, not assurance:

  • A pre-launch compliance pass on a key flow or component
  • A keyboard or screen-reader complaint has surfaced and you need the full picture
  • Reviewing a design-system component every product surface will inherit
  • The /handoff checklist raised questions that need criterion-level answers
  • WCAG 2.2 AA scorecard
  • Code-level fixes (not vague direction)
  • a11y-checklist.md
  • P0–P3 severity violations
Claude Code — /crisp-a11y
Grade: BWCAG 2.2 AA
P01.4.3 — text-muted #666 on white fails 4.5:1 contrast
P14.1.2 — role="dialog" missing aria-labelledby
P22.4.7 — focus ring hidden on primary button
→ a11y-checklist.md written to project root

Illustrative example output — not a real audit.

The audit's standing principle: prefer native HTML over ARIA patching. A native button is keyboard-accessible, focusable, and correctly announced with no extra code; a div with role="button" needs tabindex, keyboard handlers, and ARIA to imitate what the browser provides free. Any div or span acting as a control gets flagged — and the fix is almost always the correct native element, not more ARIA.

How is this different from the /handoff accessibility section?

Depth. Handoff includes a build checklist — keyboard, screen reader, visual basics. This command evaluates individual WCAG 2.2 AA success criteria, calculates contrast ratios from your actual token values, and returns exact code fixes per failure.

What does it need from me?

The component or screen, its primary interaction type — form, navigation, modal, data display — and ideally your colour token values, which turn contrast checks from approximate flags into exact ratios.

What counts as a P0?

A failure that completely blocks an assistive-technology user: a screen-reader user who cannot complete the task, or a keyboard-only user who is trapped. P0s are listed first with fixes, under the heading "fix before shipping".

Why does it mention APCA?

WCAG 2 contrast ratios are the compliance floor, but APCA models how people actually perceive text contrast more accurately. The audit uses WCAG 2 where standards require it and APCA as the design truth.

zsh
$ npx skills add @laith-wallace/crisp

Installs all fourteen CRISP skills and auto-detects your AI harness. Run /crisp-teach once per project first.

The CRISP Letter

Design evaluation, in writing.

Occasional letters on making AI agents produce work worth shipping. New skills announced here first. No noise.