Operable (In Depth)

Operable is the second POUR principle, and its premise is this: if users can't operate the controls on your site, the content doesn't matter. A page full of perfectly accessible text is useless if the navigation menu is mouse-only.

The obvious frame here is keyboard access. Keyboards are the foundational input device for accessibility. It is easy to emulate button presses into whatever format someone needs for accessibility, far easier than trying to emulate mouse movements. Getting keyboard navigation right tends to unlock support for a broad range of assistive technologies at once.

But Operable is broader than just keyboard support. It also covers timing, seizure safety, navigation tools, and more recently, the range of ways people interact with touch and pointer devices.

A note on scope: this page covers the criteria most relevant to building a typical website. A handful of niche and AAA-only criteria aren't covered here — not because they don't matter, but because they apply to narrower situations or represent an aspirational bar rather than a baseline. If you want the full picture, W3C's Understanding WCAG 2.2 — Operable has every criterion with context and examples.

Guideline 2.1 — Keyboard Accessible

Every piece of functionality accessible with a mouse must also be available with a keyboard. No exceptions for things that "inherently require" a mouse; if the functionality can be described without reference to a specific motion or gesture, it needs a keyboard path.[1]

The companion requirement is that users can't get trapped. If a component takes keyboard focus — a modal, a date picker, a video player — there has to be a way to leave it using only the keyboard. This becomes a huge issue with some embedded content. Focus traps that don't let you back out of them make it impossible to navigate a website.

These two criteria together (2.1.1 and 2.1.2) cover most keyboard accessibility concerns. A third criterion at AA, No Keyboard Shortcut (2.1.4), addresses a specific collision problem: if your site implements single-key shortcuts, users who rely on keyboard input or voice input can accidentally trigger those shortcuts while typing or dictating. Single-character shortcuts need to either be remappable or toggled off.

For most sites, this guideline comes down to: make sure all interactive elements are reachable with Tab, can be activated with Enter or Space, and that focus never gets permanently stuck anywhere.

What success looks like

  • All functionality is available from a keyboard. (2.1.1 — Level A)
  • Keyboard focus can always be moved away from any component. (2.1.2 — Level A)
  • Any single-character keyboard shortcuts can be remapped or disabled. (2.1.4 — Level A)

Guideline 2.2 — Enough Time

If your content has time limits, users need enough time to complete their tasks — or a way to extend, pause, or turn off those limits.

Time limits are a genuine barrier for users with cognitive disabilities, motor impairments, or anyone who needs longer to read, process, or respond. Session timeouts are the most common example, but this also applies to auto-advancing carousels, auto-refreshing content, and anything that triggers an action or change after a countdown.

There are a few specific cases covered here:

The exception language is important. Real-time events — a 24-hour sale countdown, live sports scores — don't have to give you extra time, because the time limit is genuinely integral to the thing. The guideline targets arbitrary or unnecessary time pressure.

What success looks like

  • Time limits can be turned off, adjusted, or extended. (2.2.1 — Level A)
  • Moving, blinking, or auto-updating content can be paused or stopped. (2.2.2 — Level A)

Guideline 2.3 — Seizures and Physical Reactions

Content shouldn't cause seizures or physical reactions. Full stop.

The specific rule is about flashing: content can't flash more than three times per second, or the flash must be below threshold for size and contrast. Flashing above that rate can trigger seizures in people with photosensitive epilepsy.

This is one of the few WCAG criteria where failure isn't about excluding users from content — it's about actively harming them. The threshold isn't conservative for the sake of it; it's calibrated to real clinical data on seizure triggers.[2]

A newer criterion at AAA — Animation from Interactions (2.3.3) — extends this to cover motion more broadly. Parallax effects, zooming animations, and spinning elements can cause nausea or disorientation for users with vestibular disorders. The AA bar doesn't require removing these, but the prefers-reduced-motion media query is the right tool for honoring users who've turned motion down at the OS level.

What success looks like

  • Content doesn't flash more than three times per second (or stays below the general and red flash thresholds). (2.3.1 — Level A)

Guideline 2.4 — Navigable

This guideline is about helping users find content and know where they are. It covers several distinct concerns that often get lumped together.

Skip navigation (2.4.1) lets keyboard users bypass repeated content — navigation menus, headers — to get to the main content. Without this, every page starts with tabbing through the entire nav. It's usually implemented as a visually hidden "Skip to main content" link at the top of the page that appears on focus.

Descriptive page titles (2.4.2) help users orient themselves. Tabs, browser history, and screen readers all surface the <title> element. "Homepage" is less useful than "Home — Site Name."

Focus order (2.4.3) needs to be logical. Keyboard focus should move through a page in an order that makes sense (generally top to bottom, left to right if the site is in English) without jumping around in ways that break comprehension or context.

Link purpose (2.4.4) is the "click here" problem. Links need to communicate their destination. Some screen reader users navigate pages quickly by listening just to link text, extracted from context. "Click here," "read more," and "learn more" are meaningless without the surrounding paragraphs. Links should make sense in isolation or be labelled with visually-hidden context.

Focus visible (2.4.7) requires that keyboard focus is visible. This sounds obvious, but CSS resets or custom styles can strip the default browser focus indicator or render it near invisible. If users can't see where the keyboard focus is, they can't navigate the page. WCAG 2.2 added Focus Appearance (2.4.11) as a AA criterion, requiring that the focus indicator meets a minimum size and contrast threshold. Browser defaults don't reliably meet it. This is worth building into your baseline styles intentionally, to ensure it works with your site's visual style.

What success looks like

  • A mechanism exists to skip repeated navigation content. (2.4.1 — Level A)
  • Pages have descriptive titles. (2.4.2 — Level A)
  • Focus moves in a logical sequence. (2.4.3 — Level A)
  • The purpose of each link can be determined from its text or context. (2.4.4 — Level A)
  • Keyboard focus indicator is visible. (2.4.7 — Level AA)
  • Focus indicator meets minimum size and contrast requirements. (2.4.11 — Level AA, new in 2.2)

Guideline 2.5 — Input Modalities

This guideline was added in WCAG 2.1 and expanded in 2.2. It's specifically about touch and pointer input — making sure your interface works for people who aren't using a standard mouse or keyboard.

Pointer gestures (2.5.1): Functionality that requires complex gestures (pinch-to-zoom, multi-finger swipes, path-based gestures) needs a single-pointer alternative. Sliders, drag-and-drop interfaces, and custom gesture controls should have button or tap-based fallbacks.

Pointer cancellation (2.5.2): Actions shouldn't trigger on the down event of a pointer — they should trigger on the up event, or be cancellable. If you activate a button the moment someone touches it (before they lift their finger), they can't change their mind or correct an accidental tap. Mouse mouseup and touch touchend are the right events; mousedown and touchstart aren't.

Label in Name (2.5.3): If a button or control has visible text, its accessible name needs to contain that text. Voice control users activate controls by speaking the label they see. If the visual label says "Submit" but the aria-label says something different, the voice command won't work.

Motion Actuation (2.5.4): Functionality triggered by device motion (shaking, tilting) needs an alternative. Users may have their device mounted or may have tremors that trigger motion events unintentionally.

WCAG 2.2 added two new criteria here: Dragging Movements (2.5.7) — any drag operation needs a single-pointer alternative — and Target Size (Minimum) (2.5.8) — touch targets need to be at least 24×24 CSS pixels, or have enough spacing that an undersized target doesn't overlap a neighboring target's activation zone.

What success looks like

  • Multipoint or path-based gestures have single-pointer alternatives. (2.5.1 — Level A)
  • Actions triggered by pointer input can be cancelled or reversed. (2.5.2 — Level A)
  • Accessible names for controls contain the visible label text. (2.5.3 — Level A)
  • Functionality via device motion has an alternative and can be disabled. (2.5.4 — Level A)
  • Drag operations have a single-pointer alternative. (2.5.7 — Level AA, new in 2.2)
  • Touch targets are at least 24×24 CSS pixels. (2.5.8 — Level AA, new in 2.2)

The throughline

What ties these five guidelines together is that they're all asking: can users who don't interact with the web the same way you do still operate this thing? That includes users without a mouse, users who need more time, users whose motor conditions make precise touch targets difficult, and users for whom flashing content is a medical hazard. Operability is about not assuming a single, standard body using a single, standard input device.

Going Deeper

Sources

  1. W3C. "Understanding Success Criterion 2.1.1: Keyboard." WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/keyboard.html (accessed May 2026) ↩
  2. W3C. "Understanding Success Criterion 2.3.1: Three Flashes or Below Threshold." WCAG 2.2. https://www.w3.org/WAI/WCAG22/Understanding/three-flashes-or-below-threshold.html (accessed May 2026) ↩