Accessibility Design

Instructions

WCAG 2.1/2.2 Four Principles — Every requirement maps to one of these:

• Perceivable — Information must be presentable in ways all users can perceive.
• Provide text alternatives for all non-text content (images, icons, charts)
• Supply captions and transcripts for audio/video content
• Maintain 4.5:1 contrast (AA) for normal text, 3:1 for large text, 7:1 for AAA
• Ensure content remains usable when resized to 200% without horizontal scrolling

• Operable — All functionality must be available through multiple input methods.
• Every interactive element must be reachable and activatable via keyboard alone
• No keyboard traps — users must always be able to navigate away
• Provide a skip navigation link as the first focusable element
• No content flashes more than 3 times per second

• Understandable — Content and operation must be clear and predictable.
• Declare the page language (lang attribute) and mark language changes inline
• Navigation and interaction must be predictable — consistent placement, consistent behavior
• Provide input assistance: visible labels, descriptive error messages, suggestions for correction

• Robust — Content must work across current and future technologies.
• Use valid, semantic HTML — validated against the spec
• Ensure every component exposes correct name, role, and value to assistive technologies

Assistive Technology Stack — Design and test across the full range:

• Screen readers: NVDA (Windows, free), JAWS (Windows, enterprise), VoiceOver (macOS/iOS), TalkBack (Android)
• Voice control: Dragon NaturallySpeaking
• Switch access: single-switch and two-switch scanning
• Eye-tracking: Tobii and similar gaze-based input systems
• Zoom/magnification: OS-level zoom, browser zoom, dedicated magnifiers

ARIA Best Practices — Use ARIA to enhance, never to replace:

• Prefer semantic HTML first — ,


  ,

  , over
• Never let aria-label contradict visible text — assistive tech users and sighted users must receive the same message
• Use aria-live="polite" for non-urgent dynamic updates and aria-live="assertive" only for critical alerts
• Manage focus explicitly in modals (trap focus inside), single-page route changes (move focus to new content), and disclosure widgets
• Validate every role, state, and property against the WAI-ARIA spec before shipping

Testing Protocol — Layered approach catches the broadest range of issues:

1. Run automated scans first (axe-core, Lighthouse, WAVE) to catch low-hanging violations
2. Perform manual keyboard-only testing — tab through every flow before shipping
3. Test with at least two screen readers (one desktop, one mobile)
4. Review alt text: describe the function or meaning of the image, not its visual appearance (e.g., “Submit form” not “green button”)
5. Evaluate cognitive accessibility: plain language, predictable layouts, clear error recovery paths
6. Include users with disabilities in usability testing whenever possible

Never Do These:

• Use color alone to convey meaning — always pair with text, icons, or patterns
• Auto-play audio or video — provide explicit play controls and default to muted
• Remove focus outlines without providing a visible custom alternative
• Use placeholder text as the only label — placeholders disappear on input and fail assistive tech parsing

Checklist before shipping:

• [ ] Automated scan reports zero critical and zero serious violations
• [ ] Complete keyboard-only walkthrough of all primary flows
• [ ] Screen reader testing confirms logical reading order and all controls announced correctly
• [ ] Contrast ratios verified for all text, icons, and interactive states
• [ ] Focus management tested in modals, drawers, and route transitions
• [ ] prefers-reduced-motion and prefers-color-scheme media queries honored
• [ ] Alt text reviewed for every image and decorative images marked alt=""
• [ ] Form inputs have visible labels, required fields indicated, and errors described