| name | design-accessibility-standards |
| description | Use when auditing or designing UI components to meet WCAG 2.2, Section 508, or ARIA accessibility requirements |
| source | WCAG 2.2 (W3C Web Content Accessibility Guidelines); Section 508 (US Rehabilitation Act); ARIA specification (W3C WAI-ARIA 1.2) |
| tags | ["accessibility","wcag","aria","a11y","inclusive-design"] |
| related | ["apply-digital-divide-diagnostic"] |
| verified | true |
Design Accessibility Standards
Ensure digital interfaces are perceivable, operable, understandable, and robust for users with disabilities, meeting legal and ethical standards.
Why This Is Best Practice
Adopted by: All US federal agencies (Section 508 mandate), EU (EN 301 549), UK (PSBAR 2018), Apple App Store accessibility review, Google Play accessibility guidelines
Impact: 1 in 4 US adults has a disability; accessible design improves usability for all users (curb-cut effect); ADA non-compliance lawsuits exceeded 4,000/year in 2022
Why best: WCAG 2.2 POUR framework (Perceivable, Operable, Understandable, Robust) provides a complete, testable taxonomy covering visual, motor, cognitive, and auditory needs.
Sources: W3C WCAG 2.2 (2023); W3C WAI-ARIA 1.2 (2023); US Section 508 (29 USC §794d)
Steps
- Set conformance target — define required level: WCAG 2.2 Level AA (legal minimum for most jurisdictions); Level AAA for healthcare or government.
- Audit color contrast — all text must meet 4.5:1 ratio for normal text, 3:1 for large text (AA); use WebAIM Contrast Checker or Figma plugins; fix by adjusting foreground or background.
- Audit keyboard navigation — tab through every interactive element; verify visible focus indicators, logical tab order, no keyboard traps; test skip navigation links.
- Audit screen reader compatibility — test with NVDA+Chrome (Windows) and VoiceOver+Safari (macOS/iOS); verify all images have alt text, icons have aria-label, and live regions announce dynamic content.
- Audit form accessibility — every input has an associated
<label>; error messages are programmatically linked to inputs via aria-describedby; required fields marked both visually and with aria-required.
- Audit ARIA usage — validate ARIA roles match element semantics; no ARIA attribute conflicts; verify landmarks (main, nav, aside, header, footer) are present and unique.
- Audit motion and animation — implement
prefers-reduced-motion for all animations; no content flashes more than 3 times per second (seizure threshold).
- Audit touch targets — minimum 44×44px touch target for all interactive elements (iOS HIG) or 48×48dp (Material); spacing between targets ≥8px.
- Audit text and readability — body text minimum 16px; line height 1.4–1.6; users can resize text 200% without loss of content or functionality.
- Run automated scan + manual review — use axe-core or Deque Axe DevTools for automated coverage (~35% of issues); manually test the remaining 65% using keyboard and screen reader.
Rules
- Automated tools catch only 30–40% of accessibility issues; manual keyboard and screen reader testing is non-negotiable.
- Color must never be the sole means of conveying information — pair with text labels, icons, or patterns.
- Focus indicators must be visible with at minimum a 3:1 contrast ratio against adjacent colors (WCAG 2.2 SC 2.4.11).
- All non-text content must have a text alternative; decorative images use
alt="" to be ignored by screen readers.
- ARIA should supplement, not replace, semantic HTML — prefer native elements (
<button>, <nav>) over ARIA roles on <div>.
Common Mistakes
- Removing focus outlines for aesthetics — keyboard users become completely lost; style focus rings, do not remove them.
- Using placeholder text as the only label — placeholder disappears on input; screen readers may not announce it as a label.
- Icon-only buttons without accessible names —
<button><svg>...</svg></button> is read as "button" by screen readers; add aria-label.
- Modal dialogs without focus trapping — keyboard focus escaping a modal creates an unusable experience for screen reader users.
- Testing only with sighted keyboard — screen reader users encounter different DOM ordering and ARIA announcement issues invisible to sighted keyboard testers.
When NOT to Use
- Internal tools with 100% verified non-disabled user base (rare; still best practice)
- Prototypes explicitly not intended for user testing (wireframes)
- Content designed exclusively for print media
