a11y

Audits and remediates web accessibility against WCAG 2.2 Level AA with tiered findings.

Updated Nov 20, 2025
One-click install
npx skills add https://github.com/apuya/react-basics-ui --skill a11y-apuya
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: a11y
Source: https://github.com/apuya/react-basics-ui/tree/main/.claude/skills/a11y
Command: npx skills add https://github.com/apuya/react-basics-ui --skill a11y-apuya

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Web components and pages often ship with accessibility defects — unreachable controls, missing labels, broken focus management — that block users with disabilities and fail WCAG conformance. This Skill audits, fixes, specifies, and explains accessibility issues against WCAG 2.2 Level AA so defects are caught with cited success criteria instead of guesswork. ## Core Features & Use Cases - Tiered Audits: Produces Blocker / High / Medium findings with success-criterion citations, plus a separate Polish tier for best-practice items below AA. - Remediation Diffs: Applies minimal inline fixes annotated with the SC each change satisfies, preferring semantic HTML over ARIA patches. - Component A11y Specs: Writes accessibility contracts for new components covering keyboard model, ARIA pattern, focus behavior, and error semantics. - Use Case: While building a React component library, run an audit on a new Modal component to verify focus trap, focus restoration to the trigger, and role="dialog" semantics before release. ## Quick Start Ask the assistant to audit a component or page for WCAG 2.2 AA accessibility issues and list the findings by severity.

Frequently Asked Questions about a11y

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a React component for WCAG 2.2 accessibility?

Run an accessibility audit that walks keyboard reachability, focus visibility, ARIA roles and names, contrast, and live regions, then reports findings by severity tier. Each Blocker, High, or Medium finding cites the specific WCAG 2.2 success criterion it violates.

What accessibility issues does axe or Storybook a11y testing catch?

Automated tools like @storybook/addon-a11y catch roughly a third of issues, mostly contrast, missing names, and ARIA misuse. Keyboard operability, focus restoration, and screen-reader announcement quality still require manual testing with Tab navigation and tools like VoiceOver or NVDA.

Does WCAG 2.2 AA require a minimum click target size?

Yes, criterion 2.5.8 requires pointer targets of at least 24 by 24 CSS pixels, or equivalent clear spacing, with exceptions for inline and essential targets. The AAA best practice from 2.5.5 recommends 44 by 44 pixels.

Why is using a div with onclick an accessibility problem?

A div with onclick is not keyboard-focusable and exposes no role or name to assistive technology, failing criteria 2.1.1 and 4.1.2. The correct fix is replacing it with a native button element, which provides focus, activation keys, and semantics for free.

When should I use ARIA instead of semantic HTML?

Use ARIA only for composite widgets HTML does not provide, such as comboboxes, trees, and tablists, or for live-region announcements. Native elements like button, a, input, and table already supply role, state, and keyboard behavior, so ARIA on top of them is redundant or harmful.