accessibility-auditorlisted

# 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-labe