JSTAcademy
0 XP
Dashboard
Human-Computer Interaction
Accessibility & Inclusive Design
16 min
PhD+200 XP
Human-Computer Interaction · PhD

Accessibility & Inclusive Design

Building for the full range of human ability — not as a compliance checkbox but as a design standard
16 min read+200 XP on completionCert: Human-Computer Interaction
Tap any word in the text below to start reading from there.

Accessibility & Inclusive Design

Approximately 1 in 7 people worldwide has a disability. In the United States, the ADA mandates accessible digital products for regulated entities. In the UK, the Equality Act has the same effect. The EU Web Accessibility Directive applies to public sector bodies. Beyond compliance, inaccessible products exclude customers, create legal liability, and reflect a design failure.

The business case is clear. Apple's accessibility features — which began as disability accommodations — are now used by the majority of iPhone users. Captioned video was an accessibility feature; it is now standard. Large text was an accessibility feature; it is now preferred by ageing populations everywhere.

Who Accessibility Affects

Disability categories relevant to interface design:

Visual — blindness (requires screen readers), low vision (requires magnification, high contrast), colour blindness (affects 8% of men; colour-only information is inaccessible).

Motor/Physical — inability to use a mouse, limited fine motor control, one-handed use, tremors. Requires keyboard navigation, larger touch targets, voice control support.

Cognitive — dyslexia, ADHD, memory impairments. Benefits from clear language, consistent layouts, reduced distractions, and error tolerance.

Auditory — deafness and hard-of-hearing. Requires captions for video and audio content.

Situational disability — a person without a disability who is temporarily impaired: holding a baby with one arm, in a loud environment, in bright sunlight, recovering from eye surgery. Accessibility features serve this vast population.

WCAG: The Technical Standard

The Web Content Accessibility Guidelines (WCAG) 2.1 and 2.2 define accessibility through four principles (POUR):

Perceivable — information must be presentable in ways all users can perceive:

  • Text alternatives for all non-text content (alt text for images)
  • Captions and transcripts for audio/video
  • Content can be presented without losing information if colour, size, or visual formatting is unavailable
  • Colour contrast: minimum 4.5:1 ratio for normal text at Level AA

Operable — users must be able to interact with all interface functionality:

  • All functionality available via keyboard (no mouse required)
  • No content that causes seizures (no flashing above 3Hz)
  • Users have enough time to read and interact with content
  • Skip navigation links let keyboard users bypass repetitive content

Understandable — information and operation must be understandable:

  • Text is readable and understandable (appropriate reading level, language declaration)
  • Pages appear and operate predictably
  • Users are helped to avoid and correct mistakes (accessible error identification)

Robust — content must be robust enough to be interpreted by diverse user agents:

  • Valid, semantic HTML that assistive technologies can parse
  • Status messages programmatically determinable so screen readers can announce them

Screen Readers and Semantic HTML

Screen readers (VoiceOver on macOS/iOS, NVDA and JAWS on Windows) convert page content to audio or braille. They navigate by semantic structure — headings, links, form labels, landmarks. An interface built with meaningless div elements and CSS-styled buttons is invisible to screen readers; it must be rebuilt with:

  • Semantic HTML elements (<button>, <nav>, <main>, <h1>–<h6>)
  • Meaningful alt text on images (not "image1.jpg"; describes what the image conveys)
  • Form labels programmatically associated with their inputs (<label for="email">)
  • ARIA attributes where HTML semantics are insufficient (live regions for dynamic content, roles for custom widgets)
  • Logical reading order in the DOM that matches visual order

Colour and Contrast

Colour alone must never convey information — combine colour with shape, text, or pattern. Red error states must also have error text and an icon. Green success states must also have text confirmation.

Contrast ratios affect readability for low-vision users and in suboptimal conditions (outdoor screens, worn displays, print). Test contrast with automated tools (Colour Contrast Analyser, browser DevTools accessibility panels, Figma plugins like Colour Contrast Checker).

Keyboard Navigation

All interactive elements must be reachable and operable via keyboard:

  • Logical tab order (matches reading order)
  • Visible focus indicators (not removed with outline: none)
  • Focus management for dynamic content (modal opens, focus moves to modal; modal closes, focus returns to trigger)
  • Custom keyboard interactions for complex widgets (arrow keys for menus, Escape to close)

Testing for Accessibility

Automated tools (axe, Lighthouse, WAVE) catch approximately 30–40% of accessibility issues. The remainder require manual testing:

  • Keyboard-only navigation — unplug or disable the mouse and navigate the entire application
  • Screen reader testing — navigate with VoiceOver (macOS/iOS) or NVDA (Windows), verifying that all content is announced and all interactions work
  • Colour contrast audit — verify all text meets WCAG AA minimum ratios
  • User testing with disabled users — the highest-fidelity method; reveals issues that technical testing misses
0%