a11y-audit
The a11y-audit skill evaluates UI components and designs against WCAG 2.2 AA/AAA standards and project-specific ARIA patterns, returning criterion-referenced findings organized by severity. Use it when accessibility verification is needed, including contrast measurement via actual render scripts, keyboard navigation review, screen-reader compatibility checks, and confirmation that components meet the POUR principle and mandatory P0 accessibility requirements.
git clone --depth 1 https://github.com/plugin87/ux-ui-agent-skills /tmp/a11y-audit && cp -r /tmp/a11y-audit/.claude/skills/a11y-audit ~/.claude/skills/a11y-auditSKILL.md
# Skill: Accessibility Audit Evaluate against WCAG 2.2 and the project's ARIA patterns. ## Steps 1. Read `accessibility/wcag-checklist.md` (POUR-organized, P0/P1/P2) and `accessibility/aria-patterns.md`. 2. Check the mandatory P0 set per component: keyboard navigable, focus visible (≥3:1), screen-reader name/role/state, contrast (4.5:1 text / 3:1 UI), target size ≥24×24, no color-only signaling. 3. Verify WCAG 2.2 additions: Focus Not Obscured (2.4.11), Target Size (2.5.8), Accessible Authentication (3.3.8). 4. **Contrast — measure, don't eyeball.** For rendered HTML, RUN the real-render gates and report their actual output (CLAUDE.md → Verification Protocol): `node scripts/measure_render.mjs <file> [--dark]` (every text element) AND `node scripts/verify_states.mjs <file> [--dark]` (every interactive element in default/hover/focus — catches hover-state failures). For loose color pairs, `python3 scripts/contrast.py "<fg>" "<bg>"`. Never state a ratio you did not measure. 5. Check reduced-motion handling (`taste/motion-choreography.md`). ## Output A findings table: WCAG criterion (e.g. 1.4.3) · severity (P0/P1/P2) · what fails · specific fix. Confirm passes explicitly. Accessibility may never be traded for aesthetics.
Apply a visual direction — an archetype (high-end agency, editorial minimal, brutalist, soft-SaaS, dark-tech) or one of 138 named design systems (apple, linear-app, stripe, vercel, notion, material, shadcn, spotify, tesla…) — by resolving it into the token system. Use when the user wants a specific look/vibe/brand feel, or asks to make a design feel premium/expensive/non-generic.
Generate a complete, accessible brand design system from a brief — primitive → semantic → component DTCG tokens (color, type, spacing, radius, shadow, motion), light + dark, plus a single theme.css — verified for WCAG. Use when the user wants a from-scratch brand/design foundation, a new palette + type system, or a themeable token kit for a product.
Adversarial design critique of the current work — render it, look at it, and argue for rejection. Run after the gates are green, never instead of them.
Generate production-ready, accessible, token-driven component code for ANY framework — React+Tailwind, Next.js, SwiftUI, Vue, Svelte, Angular, Solid, Web Components/Lit, React Native, Flutter, Jetpack Compose, vanilla CSS, or CSS-in-JS. Use when the user wants working UI code for a component or screen in a specific stack.
Design a UI component spec to the house quality bar — anatomy, variants, sizes, the 8 states, token mapping, and accessibility. Use when the user wants to design or document a component (button, input, tabs, toast, combobox, date picker, modal, etc.) at the spec level before or alongside code. For generating framework code, use design-code.
Adversarial senior design critic. Renders the work, looks at it, and argues for rejection. Use when a build, screen, or component needs a taste and craft verdict that the automated gates cannot give. Runs after the gates are green, never instead of them.
Set up or run design QA gates — token + hardcoded-value lint, automated a11y (axe), contrast, visual regression across variants/states/themes/RTL, and the manual a11y checklist. Use when the user wants CI quality gates, to prevent design regressions, or to QA a component/screen before shipping.
Review or audit a design/UI across 6 weighted dimensions with Nielsen's 10 heuristics and a prioritized findings table. Use when the user wants a design critique, quality score, heuristic evaluation, or audit of an existing screen, page, or product before/after build.