Accessibility

Why Accessibility Matters

Accessibility (a11y) ensures that products are usable by people with the widest range of abilities, in the widest range of situations. Approximately 15-20% of the global population has some form of disability.

Accessibility is not a feature --- it is a quality of the design. It benefits everyone:

• Permanent disability: Blind, deaf, motor impairment
• Temporary disability: Broken arm, ear infection, migraine
• Situational disability: Bright sunlight, noisy environment, holding a child

WCAG: Web Content Accessibility Guidelines

WCAG is the international standard (W3C) for web accessibility. Current versions: WCAG 2.1 (2018) and WCAG 2.2 (2023).

The POUR Principles

All WCAG guidelines fall under four principles:

1. Perceivable

Information and UI components must be presentable in ways users can perceive.

2. Operable

UI components and navigation must be operable by all users.

3. Understandable

Information and UI operation must be understandable.

4. Robust

Content must be robust enough to be interpreted by a wide variety of user agents, including assistive technologies.

Conformance Levels

Most legal requirements and organizational standards target Level AA.

ARIA (Accessible Rich Internet Applications)

ARIA attributes add semantic information to HTML elements for assistive technologies.

Core ARIA Concepts

<!-- Roles: what the element IS -->
<div role="button">Click me</div>
<div role="alert">Error: invalid email</div>
<nav role="navigation" aria-label="Main">...</nav>

<!-- States: current condition of the element -->
<button aria-expanded="false">Menu</button>
<input aria-invalid="true">

<!-- Properties: characteristics of the element -->
<input aria-label="Search" type="text">
<div aria-describedby="help-text">...</div>
<div aria-live="polite">3 new messages</div>

ARIA Rules

1. Do not use ARIA if native HTML works. <button> is better than <div role="button">.
2. Do not change native semantics unless necessary.
3. All interactive ARIA controls must be keyboard accessible.
4. Do not use role="presentation" or aria-hidden="true" on focusable elements.
5. All interactive elements must have an accessible name.

Live Regions

Announce dynamic content changes to screen readers:

<!-- polite: announced at next pause -->
<div aria-live="polite">Cart updated: 3 items</div>

<!-- assertive: announced immediately, interrupts -->
<div aria-live="assertive">Session expiring in 60 seconds</div>

<!-- Specialized live region roles -->
<div role="alert">Error: password too short</div>  <!-- implicitly assertive -->
<div role="status">File uploaded successfully</div> <!-- implicitly polite -->

Screen Readers

Screen readers convert on-screen content to speech or Braille output.

How Screen Readers Navigate

• Heading navigation (H key): Jump between headings. Proper heading hierarchy (h1 > h2 > h3) is essential.
• Landmark navigation: Jump between <nav>, <main>, <aside>, <footer>.
• Tab key: Move between interactive elements (links, buttons, form fields).
• Screen reader cursor: Arrow keys to read content linearly.
• Forms mode: Interact with form controls.

Writing for Screen Readers

<!-- Image alt text -->
<img src="chart.png" alt="Bar chart showing Q3 revenue up 15% from Q2">
<img src="decorative-line.png" alt="">  <!-- decorative: empty alt -->

<!-- Link text -->
BAD:  <a href="...">Click here</a>
GOOD: <a href="...">Download 2025 annual report (PDF, 2.4MB)</a>

<!-- Form labels -->
BAD:  <input type="email">
GOOD: <label for="email">Email address</label>
      <input type="email" id="email" autocomplete="email">

Keyboard Navigation

All interactive functionality must be accessible via keyboard alone.

Essential Keyboard Patterns

Focus Management

/* Never do this without replacement: */
*:focus { outline: none; }  /* DESTROYS keyboard accessibility */

/* Instead, provide visible focus indicators: */
:focus-visible {
    outline: 3px solid #2563EB;
    outline-offset: 2px;
}

Focus trapping: Modal dialogs must trap focus within the dialog. Tab should cycle through dialog elements only, not reach the page behind.

Focus restoration: When a modal closes, return focus to the element that triggered it.

Color and Contrast

Contrast Requirements (WCAG 2.1)

Color Independence

Never convey information through color alone:

Form validation:
  BAD:  Red border on error fields (color only)
  GOOD: Red border + error icon + error message text

Data visualization:
  BAD:  Red line vs green line (indistinguishable for color-blind users)
  GOOD: Red dashed line vs green solid line + labeled legend

Captions and Transcripts

Caption quality: Captions should include speaker identification, sound effects [door slams], and music descriptions [upbeat jazz].

Cognitive Accessibility

Design for users with cognitive and learning disabilities (dyslexia, ADHD, autism, intellectual disabilities, acquired brain injuries).

• Clear language: Short sentences, common words, avoid jargon
• Consistent navigation: Same layout and patterns across pages
• Error recovery: Clear error messages, undo capability, confirmation for destructive actions
• Predictable behavior: No unexpected changes, no auto-advancing content
• Chunked content: Break information into small, manageable pieces
• Multiple formats: Support text, images, audio, and video for the same content
• Minimal distractions: Allow users to hide non-essential content, reduce motion

Motor Accessibility

Design for users with limited motor control (tremors, paralysis, repetitive strain, missing limbs).

• Large touch targets: Minimum 44x44px (Apple) / 48x48dp (Android) / 24x24 CSS px (WCAG 2.2 AA)
• Adequate spacing: Prevent accidental activation of adjacent targets
• No complex gestures required: Multi-finger gestures need single-pointer alternatives
• No time-dependent actions: Allow users to extend or remove time limits
• Switch access: Support for single-switch and sip-and-puff devices
• Voice control: Ensure visible labels match accessible names

Assistive Technologies

Testing for Accessibility