Accessibility

Accessibility

Accessibility is the property of a design that lets it be used by the widest plausible range of people, including people with permanent, temporary, and situational impairments. It is not "compliance polish"; it is structural. A design that is bolted on top of an inaccessible foundation will always be partially accessible at best, and the cost to retrofit climbs quickly.

Definition (in our own words)

A design is accessible to the extent that people can perceive its content, operate its controls, understand what it tells them, and rely on it across the assistive technologies they use. The four verbs — perceive, operate, understand, robust — are not arbitrary; they are the four sub-principles of the Web Content Accessibility Guidelines (WCAG), and they cover the full surface area of what can fail when a person who isn't a designer's idealized user encounters a design.

Origins and research lineage

• WCAG 1.0 (1999) was the first formal web accessibility specification, published by the W3C's Web Accessibility Initiative (WAI).
• WCAG 2.0 (2008) introduced the four-principle framework (Perceivable, Operable, Understandable, Robust) that grounds modern web accessibility practice.
• WCAG 2.1 (2018) and WCAG 2.2 (2023) added criteria for mobile, low-vision, and cognitive disabilities.
• Section 508 (US, 1998 onward) and the European Accessibility Act (EAA, full effect 2025) make accessibility a legal requirement for many public-facing software products in their jurisdictions.
• Inclusive Design (Microsoft Inclusive Design Toolkit; the work of Kat Holmes, Susan Goltsman, Annie Jean-Baptiste) reframes accessibility as designing for the spectrum of human diversity rather than for "users with disabilities" as a separate category.

The takeaway: accessibility is a four-decade discipline with established principles, measurable criteria, and increasingly serious legal teeth.

Why accessibility matters

The business case is often presented as either ethical ("it's the right thing to do") or compliance ("we'll get sued"). Both are real. But the deeper case is that accessibility is good design that's been measured against the hardest cases.

The user with a screen reader is the user who needs your label-input pairing to be programmatically associated. Every user benefits when it is. The user with low vision is the user who needs your contrast ratio to clear 4.5:1. Every user benefits when contrast is good. The user with a motor impairment is the user who needs your hit targets to be 44×44. Every user — including users on a phone in motion, in glare, with a cracked screen, or one-handed — benefits.

Accessibility raises the floor for everyone. The disabled user is the canary; if the design works for them, it works under the broader range of conditions everyone occasionally faces.

The numbers in any modern audience:

• ~15% of any population has a long-term disability (WHO).
• ~8% of men have red-green color blindness; ~0.5% of women.
• ~25% of adults over 65 have meaningful vision loss.
• 100% of users will eventually be in some form of degraded condition (sun glare, motion, fatigue, distraction, broken finger).

When to apply

• Every design task. Yes, every one.
• Most pointedly: at the start. Bake accessibility into the design phase rather than retrofit at the end. Retrofitting is 2–10x the cost of building it in.
• At every design review. Add an accessibility check to the review template.
• In component design (design system). Get the primitives right and every consumer of them inherits the accessibility for free.

When NOT to apply

There is no surface on which accessibility doesn't apply. The relative weight of different criteria varies (a marketing landing page is mostly Perceivable + Operable; a complex form is mostly Operable + Understandable), but no surface is exempt.

The four sub-principles (WCAG framework)

WCAG organizes accessibility into four categories. Each gets its own sub-aspect skill in this plugin; this section is the overview.

Perceivable

Users must be able to perceive the content via at least one of their senses. The system must not present information in a way that requires a sense the user doesn't have access to.

Decisions in scope:

• Text alternatives for images, icons, video, audio.
• Color and contrast between text and background, between meaningful UI elements.
• Color is never the only signal for meaningful information.
• Text scaling without breaking the layout.
• Reflow on small screens or zoomed displays.
• Captions and transcripts for audio/video.

Operable

Users must be able to operate the controls — including users who don't use a mouse or finger. Keyboards, switch devices, voice control, eye-tracking, and screen-reader gestures all need to work.

Decisions in scope:

• Keyboard reachability — every interactive element must be focusable and operable with Tab, Enter, Space, Esc, and arrow keys as appropriate.
• Visible focus indicators so the user can see where they are.
• Skip links so keyboard users don't tab through 50 nav items to reach content.
• No keyboard traps — focus must always be able to leave a region.
• Motion sensitivity — respect prefers-reduced-motion; provide pause/stop for any auto-moving content.
• Touch target size — at least 24×24 px (WCAG 2.5.8 AA); 44×44 strongly preferred.
• No timing-out failures without warning and extension.

Understandable

Content and behavior should be predictable and recoverable. Error messages explain what went wrong and what to do. Labels describe what they label. Navigation is consistent across pages.

Decisions in scope:

• Language declared (<html lang="en">) so screen readers pronounce correctly.
• Predictable behavior — components don't change context unexpectedly (e.g., selecting a <select> shouldn't auto-submit a form without warning).
• Error identification — when an input is invalid, explain why in text, near the field, with aria-describedby.
• Labels and instructions — every input has a label; complex inputs have clear instructions.
• Consistent navigation — same nav in the same place across pages.

Robust

The markup should work with current and future assistive technologies. Use semantic HTML where possible; use ARIA correctly when you need to extend semantics; never invent UI primitives that strip the accessibility from the underlying elements.

Decisions in scope:

• Semantic HTML first — <button>, <a>, <nav>, <main>, <form>, <label>. Use them for what they're for.
• ARIA second, only when needed — aria-label, aria-labelledby, aria-describedby, role, aria-expanded, aria-current. Wrong ARIA is often worse than no ARIA.
• Status messages — use aria-live="polite" (or assertive) for dynamic content that screen readers should announce (toasts, validation, search results).

A practical accessibility checklist (for any design)

Run through this for every screen:

PERCEIVABLE
  [ ] Every image has alt text (or alt="" if decorative).
  [ ] Every icon-only button has aria-label.
  [ ] Color contrast ≥ 4.5:1 for body text, ≥ 3:1 for large/UI elements.
  [ ] Color is never the only signal for status, required fields, or meaning.
  [ ] Layout survives 200% browser zoom without horizontal scroll.
  [ ] Page has a single <h1>; heading levels are nested (h1 → h2 → h3), not skipped.

OPERABLE
  [ ] Every interactive element is keyboard-reachable via Tab.
  [ ] Visible focus ring on every focusable element (don't outline:none without a replacement).
  [ ] Esc closes any open overlay (Dialog, Sheet, Popover, Combobox).
  [ ] Focus is trapped inside open modals; focus returns to the trigger when closed.
  [ ] Skip-to-main link present, visible on focus.
  [ ] Touch targets ≥ 44×44 (or ≥ 24×24 with adequate spacing).
  [ ] prefers-reduced-motion is respected (no critical motion).

UNDERSTANDABLE
  [ ] Every input has a programmatically associated <label> (or aria-label / aria-labelledby).
  [ ] Errors are inline, named, and offer a fix.
  [ ] Form behavior doesn't change context unexpectedly on input change.
  [ ] Required fields are marked with both a visual indicator and aria-required.
  [ ] <html lang> is set.

ROBUST
  [ ] Use <button>, <a>, <input>, etc. for what they're for.
  [ ] If you need a custom interactive element, give it the right role, tabindex, and keyboard handlers.
  [ ] Live regions (aria-live) used for dynamic announcements (toast, validation, search).
  [ ] Screen-reader test with NVDA / VoiceOver / TalkBack on critical flows.

Worked examples

Example 1: an icon-only "search" button

Anti-pattern:

<div onclick="search()" style="cursor: pointer;">
  <SearchIcon />
</div>

Not focusable, no role, no label, not a button. Screen readers say nothing useful; keyboard users can't reach it.

Right:

<button onclick="search()" aria-label="Search">
  <SearchIcon aria-hidden="true" />
</button>

Native <button> (focusable, keyboard-operable, has button role). aria-label provides the accessible name. The icon is aria-hidden because the label already describes the action.

Example 2: an inline form error

Anti-pattern:

<input type="email" />
<!-- after submit -->
<p style="color: red;">Invalid</p>

The error isn't programmatically associated with the input. Screen readers announce the input without the error; sighted users with low vision may not see "Invalid" if it's small or low-contrast.

Right:

<div class="field">
  <label for="email">Email</label>
  <input
    id="email"
    type="email"
    aria-invalid="true"
    aria-describedby="email-error"
  />
  <p id="email-error" class="field-error">
    Please enter a valid email address (e.g., name@example.com).
  </p>
</div>

aria-invalid flags the input as in error; aria-describedby ties the message to the input so screen readers announce both together. The message text is specific and offers a fix.