--- model_tier: medium name: accessibility-auditor description: "Use when reviewing UI for accessibility — WCAG 2.2 AA, keyboard nav, focus, ARIA, contrast, screen-reader semantics — even on 'is this a11y-OK?' or 'mach das barrierefrei'." personas: - frontend-engineer domain: quality workspaces: - engineering packs: - engineering-base token_budget_class: rich --- # accessibility-auditor > Audit a UI surface against WCAG 2.2 AA, keyboard-only operation, > and screen-reader semantics. Output is a verdict with cited > failures, not a vibes check. Pair with > [`tailwind-engineer`](../tailwind-engineer/SKILL.md) for token-level > contrast fixes and [`ui-component-architect`](../ui-component-architect/SKILL.md) > for structural fixes (landmarks, heading order). ## When to use - A new screen, component, or form lands and a11y has not been reviewed yet. - A bug report mentions keyboard, screen reader, focus order, contrast, or "user can't reach the X button". - A modal, dropdown, popover, tab strip, or tree view is being introduced — these are the highest-yield bug zones. - German triggers: "barrierefrei prüfen", "Tastatur-Bedienung", "Screenreader testen". Do NOT use when: - The visual design itself is the question (palette, type scale) — route to [`fe-design`](../fe-design/SKILL.md). - The diff has no UI surface — accessibility audits without a UI are speculation. - A specific component spec is missing entirely — get the component built first via the stack-specific skill, then audit. ## Procedure ### 1. Identify the interaction surfaces List every interactive element on the screen: links, buttons, inputs, custom widgets (combobox, tab, dialog, tree). Each row gets a verdict in step 5; missing one is a coverage failure. ### 2. Walk the four checklists **Perceivable** — text alternatives for non-text (`alt`, `aria-label`), contrast ≥ 4.5:1 for body / 3:1 for large or UI components, no colour-only state ("error in red" must also be iconic or text). Grounded reference for palette + chart verdicts: the adopted corpus's WCAG-adjusted token sets (`--domain color`), chart a11y grades + colorblind fallbacks (`--domain chart`), and mobile touch/a11y rules (`--domain web`, 44pt targets) via [`design-intelligence`](../design-intelligence/SKILL.md) — cite the corpus row; the WCAG 2.2 AA *method* stays this skill's own checklists. Widget-pattern selection (dialog, combobox, tabs, toast, table, form errors, drag-reorder …) grounds in the ARIA-APG corpus: `./scripts-run /corpus-grounding/scripts/ground search --manifest /accessibility-auditor/data/manifest.json ""` → pattern, implementation, WCAG refs, anti-patterns ([`data/aria-patterns.csv`](data/aria-patterns.csv)). **Operable** — every interactive element reachable by `Tab`, focus order matches visual order, focus indicator visible (≥ 3:1 against adjacent), `Esc` closes overlays, no keyboard traps. **Understandable** — labels associated (`label[for]` or wrapping), errors named in text (not just border colour), language attribute on ``, predictable navigation across pages. **Robust** — landmarks present (`
`, `