Accessibility Operable

Accessibility — Operable

WCAG Principle 2: user-interface components and navigation must be operable.

The five sub-criteria, simplified:

1. Keyboard accessible — everything that works with mouse must work with keyboard.
2. Enough time — timing-out interactions are warned and extendable.
3. Seizures and physical reactions — no flashing content; respect motion preferences.
4. Navigable — users can find content and know where they are.
5. Input modalities — touch and other input methods supported with adequate target size.

1. Keyboard accessible

Every interactive element is reachable via Tab

The default Tab order follows DOM source order and only includes natively focusable elements: <a href>, <button>, <input>, <select>, <textarea>, <summary>, <iframe>, plus elements with tabindex="0".

• Use semantic elements. <button>, not <div onclick>.
• Use tabindex="0" to add custom interactive elements to tab order.
• Use tabindex="-1" to make an element programmatically focusable (e.g., for focus management) but not reachable via Tab.
• Avoid tabindex > 0. Positive tabindex creates a custom tab order that's almost always worse than DOM order and bewilders screen readers.

Visible focus indicators

The user must see where focus is. Browsers provide default focus rings; never outline: none without a replacement.

/* Right: replace, don't remove */
:focus { outline: none; }
:focus-visible {
  outline: 2px solid hsl(220 90% 50%);
  outline-offset: 2px;
  border-radius: 0.25rem;
}

/* Wrong: removes the only signal a keyboard user has */
*:focus { outline: none; }

:focus-visible (rather than :focus) shows the ring only when focus arrived via keyboard (or non-pointer means), not on every mouse click. This addresses the historical "designers don't want focus rings on click" concern without sacrificing keyboard accessibility.

Standard keys for standard interactions

Honor user expectations:

ARIA Authoring Practices Guide documents canonical keyboard interactions for every common pattern.

No keyboard traps

A keyboard trap is a region where focus enters and cannot leave via keyboard alone. Common offenders:

• Custom datepickers without arrow-key escape.
• Embedded iframes with their own focus management that don't release.
• Modal dialogs without Esc to close.

Test: keyboard-only walkthrough. If you ever get stuck and have to mouse to escape, you have a trap.

Focus management for overlays

When a modal opens:

1. Move focus into the modal (typically the first focusable element, or a "primary" focus target).
2. Trap focus inside until the modal closes.
3. Restore focus to the trigger element when the modal closes.

// Pseudocode — in practice use a library that handles edge cases
function openModal(modal, trigger) {
  modal.dataset.previousFocus = trigger;
  const focusables = modal.querySelectorAll('a, button, input, [tabindex="0"]');
  focusables[0]?.focus();
  // ... trap focus on Tab/Shift+Tab within `focusables` ...
}

function closeModal(modal) {
  modal.previousFocus?.focus();
}

Most accessible UI libraries (Radix UI, React Aria, headless component sets) do this automatically. Custom-built modals that skip focus management are inaccessible.

Skip links

<a href="#main" class="skip-link">Skip to main content</a>
<header><nav>... 50 nav items ...</nav></header>
<main id="main">...</main>

<style>
  .skip-link {
    position: absolute;
    left: -10000px;
    top: auto;
  }
  .skip-link:focus {
    position: fixed;
    top: 8px; left: 8px;
    padding: 8px 16px;
    background: black; color: white;
    z-index: 100;
  }
</style>

Keyboard users tab past nav to reach content quickly. Visible only on focus so it doesn't clutter sighted-mouse-user views.

2. Enough time

Adjustable timing

If the system has timeouts (session expiry, captcha re-verify, time-limited form), users must be able to:

• Turn it off, OR
• Extend it, OR
• Adjust it (across a wide range, ≥ 10× default).

Exceptions: real-time events (auctions), where time limit is essential.

<!-- Right: warn before timeout, allow extension -->
<dialog open>
  <h2>Session about to expire</h2>
  <p>You have 60 seconds before your session ends.</p>
  <button onclick="extendSession()">Stay signed in</button>
</dialog>

No moving / blinking content (without controls)

Content that auto-moves, blinks, or scrolls for more than 5 seconds must be pause-able / stop-able.

This includes carousels, animated banners, news tickers, autoplaying video.

3. Seizures and physical reactions

Three flashes or below

WCAG 2.3.1: don't have content that flashes more than 3 times per second. Photosensitive epilepsy can be triggered by flashing in the 3–55 Hz range.

In practice, this rules out: rapid strobe effects, blinking text (don't), high-contrast flashing animations.

Motion preferences

WCAG 2.3.3: respect prefers-reduced-motion. Many users (vestibular disorders, migraine, motion sensitivity) have configured their OS to request reduced motion.

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

For specific motion that's meaningful (a state change indicator), allow it but make it briefer / less dramatic in reduced-motion mode.

4. Navigable

Page titles

Every page has a unique, descriptive <title>:

<title>Settings — Notifications — Acme</title>

Screen reader users hear the title on page load; tab labels show it; browser history relies on it. Generic "Acme" titles for every page are useless.

Focus order matches reading order

When a user tabs through a page, focus should follow the visual / logical reading order. CSS-rearranged elements (Grid, Flex order) can break this — test.

Link purpose

Links should be understandable from their text alone (or from text + immediately-adjacent context). Screen reader users navigate by listing all links.

<!-- Wrong: "click here" tells the screen reader user nothing -->
<p>To read more, <a href="/blog/post">click here</a>.</p>

<!-- Right: link text describes destination -->
<p>Read more in <a href="/blog/post">our annual review</a>.</p>