Accessibility as Design: Building for Every Human

What & Why

Accessibility is not a feature you bolt on at the end. It is a design philosophy that shapes every decision from the first wireframe to the last line of code.

Roughly 15-20% of the global population has some form of disability. That includes permanent conditions (blindness, deafness, motor impairments), temporary ones (a broken arm, an ear infection), and situational ones (bright sunlight on a screen, holding a baby with one hand, a noisy environment). Designing for accessibility means designing for the full spectrum of human ability.

The curb cut effect demonstrates why this matters beyond compliance: features designed for accessibility benefit everyone. Closed captions help people in noisy airports. Keyboard navigation helps power users who prefer not to use a mouse. High contrast text is easier to read for everyone in bright sunlight. Good accessibility is good design.

WCAG provides the framework. It organizes accessibility into four principles (POUR), three conformance levels (A, AA, AAA), and dozens of specific success criteria. This post covers the principles, the mental models behind assistive technology, and the design patterns that make interfaces work for everyone.

How It Works

The POUR Principles

Perceivable: Information must be presentable in ways all users can perceive. This means text alternatives for images, captions for video, sufficient color contrast, and content that does not rely solely on color to convey meaning.

Operable: All functionality must be available from a keyboard. No interaction should require a mouse. Time limits must be adjustable. Content must not cause seizures (no flashing more than 3 times per second).

Understandable: Text must be readable. The interface must behave predictably. Users must get help with errors. Language must be identified so screen readers use the correct pronunciation.

Robust: Content must be compatible with current and future assistive technologies. This means valid HTML, proper ARIA usage, and semantic markup.

The Screen Reader Mental Model

Sighted users see a 2D visual layout. Screen reader users experience a linear, sequential stream of content. They navigate by headings, landmarks, links, and form controls. The visual layout is irrelevant to them. What matters is the DOM order and semantic structure.

This is why semantic HTML matters so much. A <div onclick="..."> styled to look like a button is invisible to screen readers as an interactive element. A <button> element is automatically announced as "button," receives keyboard focus, and responds to Enter and Space keys.

Keyboard Navigation

All interactive elements must be reachable and operable via keyboard alone. The standard keys:

• Tab: Move focus to the next interactive element
• Shift+Tab: Move focus to the previous interactive element
• Enter/Space: Activate the focused element (buttons, links)
• Arrow keys: Navigate within composite widgets (menus, tabs, radio groups)
• Escape: Close modals, dismiss popups

Focus indicators (the visible outline around the focused element) must never be removed with outline: none without providing an alternative. Removing focus indicators makes keyboard navigation impossible.

Color and Vision

Approximately 8% of men and 0.5% of women have some form of color vision deficiency. The most common type is red-green color blindness (deuteranopia/protanopia).

WCAG contrast requirements:

• AA (minimum): 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt+ bold)
• AAA (enhanced): 7:1 for normal text, 4.5:1 for large text
• Non-text elements: 3:1 for UI components and graphical objects

Beyond contrast, never use color as the sole indicator of meaning. Error states should use icons and text alongside red. Charts should use patterns or labels in addition to colors.

Designing for Cognitive Disabilities

Cognitive accessibility is often overlooked but affects the largest population. Design patterns that help:

• Clear, simple language: Short sentences, common words, no jargon without explanation
• Consistent navigation: Same layout and controls on every page
• Predictable behavior: No unexpected changes, no auto-playing media
• Error forgiveness: Undo, confirmation dialogs, autosave
• Reduced animation: Respect prefers-reduced-motion media query
• Chunked content: Break long content into sections with clear headings
• Visual hierarchy: Use size, weight, and spacing to show what is important

Complexity Analysis

Accessibility has quantifiable metrics that can be measured and tracked:

The relative luminance $L$ of a color is calculated from its sRGB components:

Where each linear component is derived from the sRGB value:

The contrast ratio between two colors is then:

This produces a value between 1:1 (identical colors) and 21:1 (black on white). Automated tools compute this instantly, but understanding the formula helps when debugging edge cases.

For a page with $n$ interactive elements, the keyboard accessibility coverage is:

WCAG Level A requires $A_{\text{keyboard}} = 100\%$. There are no partial passes.

Implementation

ALGORITHM CheckContrastRatio(foreground, background)
  INPUT: foreground: { r, g, b } (sRGB 0-255),
         background: { r, g, b } (sRGB 0-255)
  OUTPUT: { ratio, passesAA, passesAAA }

  FUNCTION linearize(channel)
    srgb ← channel / 255
    IF srgb <= 0.04045 THEN
      RETURN srgb / 12.92
    ELSE
      RETURN ((srgb + 0.055) / 1.055) ^ 2.4
    END IF
  END FUNCTION

  FUNCTION relativeLuminance(color)
    rLin ← linearize(color.r)
    gLin ← linearize(color.g)
    bLin ← linearize(color.b)
    RETURN 0.2126 * rLin + 0.7152 * gLin + 0.0722 * bLin
  END FUNCTION

  L1 ← relativeLuminance(foreground)
  L2 ← relativeLuminance(background)

  lighter ← max(L1, L2)
  darker ← min(L1, L2)

  ratio ← (lighter + 0.05) / (darker + 0.05)

  RETURN {
    ratio: round(ratio, 2),
    passesAA: ratio >= 4.5,
    passesAAA: ratio >= 7.0,
    passesAALargeText: ratio >= 3.0
  }
END ALGORITHM

ALGORITHM AuditKeyboardAccessibility(page)
  INPUT: page: DOM tree of the page
  OUTPUT: { coverage, issues }

  interactiveElements ← findAll(page, "button, a[href], input, select,
                                       textarea, [tabindex], [role=button],
                                       [role=link], [role=checkbox]")
  issues ← empty list
  reachableCount ← 0

  FOR EACH element IN interactiveElements DO
    isFocusable ← element.tabIndex >= 0
                   OR element is natively focusable
    hasVisibleFocus ← element has visible focus indicator
    isOperable ← element responds to Enter or Space

    IF NOT isFocusable THEN
      issues.append({
        element: element,
        issue: "Not reachable via Tab key"
      })
    ELSE IF NOT hasVisibleFocus THEN
      issues.append({
        element: element,
        issue: "No visible focus indicator"
      })
    ELSE IF NOT isOperable THEN
      issues.append({
        element: element,
        issue: "Not operable via keyboard"
      })
    ELSE
      reachableCount ← reachableCount + 1
    END IF
  END FOR

  total ← length(interactiveElements)
  coverage ← IF total > 0 THEN (reachableCount / total * 100) ELSE 100

  RETURN {
    coverage: coverage,
    totalElements: total,
    passesWCAG: coverage = 100,
    issues: issues
  }
END ALGORITHM

ALGORITHM AuditHeadingHierarchy(page)
  INPUT: page: DOM tree
  OUTPUT: { isValid, issues }

  headings ← findAll(page, "h1, h2, h3, h4, h5, h6") in DOM order
  issues ← empty list
  previousLevel ← 0

  FOR EACH heading IN headings DO
    currentLevel ← heading.tagLevel (1-6)

    IF currentLevel > previousLevel + 1 THEN
      issues.append({
        element: heading,
        issue: "Skipped from h" + previousLevel + " to h" + currentLevel
      })
    END IF

    previousLevel ← currentLevel
  END FOR

  RETURN {
    isValid: length(issues) = 0,
    issues: issues
  }
END ALGORITHM

Real-World Applications

• Apple's VoiceOver: Deeply integrated screen reader that works across macOS and iOS. Apple's commitment to semantic UI frameworks means most native apps are accessible by default
• YouTube's auto-captions: AI-generated captions make video content perceivable for deaf and hard-of-hearing users, and also help in noisy environments (curb cut effect)
• Dark mode: Originally an accessibility feature for light sensitivity, now a mainstream preference. Demonstrates the curb cut effect at scale
• Gov.uk design system: The UK government's design system is built accessibility-first, with every component tested with assistive technologies. It serves as a model for accessible design systems
• Reduced motion preferences: The prefers-reduced-motion CSS media query lets sites respect users who experience motion sickness or vestibular disorders from animations
• Slack's screen reader support: Slack invested heavily in ARIA landmarks, live regions for new messages, and keyboard shortcuts, making a complex real-time app navigable without a mouse
• High contrast mode: Windows High Contrast Mode overrides all colors to user-chosen palettes. Sites that use semantic CSS (not hardcoded colors for meaning) work automatically
• Linear's keyboard-first design: Every action in Linear is reachable via keyboard shortcuts, making it fully operable without a mouse. This serves both accessibility and power-user efficiency
• Stripe's accessible checkout: The embedded payment form uses ARIA live regions to announce validation errors, proper label associations, and logical tab order, making payments accessible to screen reader users
• GitHub's skip-to-content link: A hidden link that becomes visible on focus, letting keyboard users skip past the navigation header directly to the main content. A simple pattern with outsized impact

Key Takeaways

• Accessibility is a design philosophy, not a checklist. It shapes decisions from information architecture to color choices to interaction patterns
• WCAG's POUR principles (Perceivable, Operable, Understandable, Robust) provide the framework. Level AA conformance is the standard target for most products
• Screen reader users experience a linear, sequential stream of content. Semantic HTML and proper heading hierarchy are what make a page navigable for them
• Keyboard accessibility requires 100% coverage: every interactive element must be reachable via Tab and operable via Enter/Space. There is no partial pass
• Color contrast ratios are mathematically defined (4.5:1 for AA). Never rely on color alone to convey meaning
• Cognitive accessibility benefits the largest population and produces the broadest curb cut effects: clear language, consistent navigation, predictable behavior, and error forgiveness help everyone