Install any skill in seconds. Free to start, no credit card required.
Get Started Free →jpoindexter/accessibility-and-inclusive-design
Reference-grade guide to shipping WCAG 2.2 AA accessible, inclusively designed interfaces across web, native iOS/Android, and desktop — semantic-first markup, contrast/APCA, keyboard, screen readers, forms, touch/motor, motion/cognition, testing, and the legal floor (EAA/Section 508).
Passed 24 of 24 test cases with the skill, and 22 of 24 without it.
2 fixed22 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
The instructions your model reads when the skill loads.
Accessibility is not a feature toggle or a final-pass audit — it is a property of correct UI construction. Build it in or rebuild it later. This is the bar for production: WCAG 2.2 Level AA, every screen, every platform. Automated tools catch ~30% of issues; the rest is keyboard, screen reader, and judgment. Treat this document as the working reference, not an aspiration.
WCAG is organized under four principles. Memorize them; every requirement maps to one.
| Principle | Means | Failure example |
|---|---|---|
| Perceivable | Users can perceive the content (sight, sound, touch) | Image with no alt; 2:1 contrast text |
| Operable | Users can operate the UI (any input method) | Control reachable by mouse only |
| Understandable | Content and operation are predictable | Error says "invalid input" with no fix |
| Robust | Works with current and future assistive tech (AT) | Custom <div> widget with no role/state |
Conformance levels: A (must — basics, keyboard, alt text), AA (the legal/industry target — contrast, reflow, focus, names), AAA (aspirational, not required wholesale — 7:1 contrast, sign language). Ship AA. Conformance is per-page and all-or-nothing: a page conforms only if every applicable success criterion (SC) at that level is met, with no AT-blocking content anywhere in the page or in any process (e.g. checkout) it belongs to.
These are the ones teams miss because they post-date most a11y muscle memory. All are AA unless noted.
| SC | Name | Requirement |
|---|---|---|
| 2.4.11 | Focus Not Obscured (Minimum) | When an element gets keyboard focus, it is not entirely hidden by author content (sticky headers, cookie bars, chat widgets). |
| 2.4.12 | Focus Not Obscured (Enhanced) | AAA — focus indicator not obscured at all. |
| 2.4.13 | Focus Appearance | The focus indicator is at least as large as a 2px-thick perimeter of the component and has ≥3:1 contrast between focused/unfocused states. (AAA, but treat as the design target.) |
| 2.5.7 | Dragging Movements | Any drag operation has a single-pointer alternative (e.g. click-to-move, tap targets, up/down buttons) unless dragging is essential. |
| 2.5.8 | Target Size (Minimum) | Interactive targets are ≥24×24 CSS px, OR have ≥24px spacing to neighbors, OR are inline in a sentence. (AAA 2.5.5 wants 44px.) |
| 3.2.6 | Consistent Help | If help (contact, chat, FAQ link) appears on multiple pages, it appears in the same relative order each time. |
| 3.3.7 | Redundant Entry | Don't make users re-enter info they already gave in the same process — autofill it or let them select it. |
| 3.3.8 | Accessible Authentication (Minimum) | No cognitive function test (memorize/transcribe a password, solve a puzzle, identify objects) as the only way to authenticate. Allow password managers (don't block paste), email/OTP, passkeys, WebAuthn. |
One SC (4.1.1 Parsing) was removed in 2.2 — modern parsers handle duplicate IDs/malformed markup. Still write valid HTML; it just isn't a conformance line anymore.
Color is the most-failed category in automated scans. Two independent rules: contrast ratios, and never-color-alone.
| Content | Min ratio (AA) | AAA |
|---|
test cases passed, vs 22 / 24 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.