Operable — WCAG Principle 2

Why it matters

Perceivable content is only useful if the user can also operate the interface. The Operable principle addresses the physical and motor dimensions of accessibility: can users navigate, activate controls, and complete tasks using their available input methods — including keyboard, switch, voice, and other AT? (BoK p. 40)

Guideline 2.1: Keyboard accessible

Every function available through a mouse or touch interface must also be available through a keyboard alone. Users who are blind (using a screen reader), users with motor disabilities (using a keyboard, switch, or voice control), and users who simply prefer keyboard navigation all depend on complete keyboard access. (BoK p. 40)

Key requirements:

• All interactive elements (links, buttons, form fields, custom widgets) must receive keyboard focus and be activatable with keyboard commands.
• Users must not become trapped in a component — they must always be able to navigate away using standard keyboard keys.
• Keyboard shortcuts, if provided, must not conflict with existing system or AT shortcuts.

A missing keyboard path for a single function — a date picker accessible only via drag-and-drop, a modal dismissible only by clicking the close button — is a keyboard accessibility failure.

Guideline 2.2: Enough time

Users must have sufficient time to complete tasks. Time constraints are a significant barrier for users with motor disabilities, cognitive disabilities, and some visual disabilities who navigate more slowly. (BoK p. 40)

• If a time limit is set, users must be able to turn it off, adjust it, or extend it (with at least one warning before expiration). Exceptions apply where the time limit is essential (real-time events, auction deadlines).
• Moving, blinking, or scrolling content that starts automatically and lasts more than five seconds must be pausable, stoppable, or hideable.
• Auto-updating content must also be controllable.

Guideline 2.3: Seizures and physical reactions

Content must not flash at a rate that could trigger photosensitive seizures. The standard threshold is three flashes or fewer per second. Content that exceeds this threshold must either be eliminated or marked with a warning so that users can choose not to view it. (BoK p. 40)

Guideline 2.4: Navigable

Users must be able to navigate to the content they need without excessive effort. Key requirements: (BoK p. 40)

• Bypass blocks: provide a mechanism (skip navigation link) to bypass repeated navigation and jump to main content.
• Page titles: each page must have a descriptive title that identifies its topic or purpose.
• Focus order: the keyboard navigation sequence must follow a logical order that preserves meaning and operability.
• Link purpose: the purpose of each link must be determinable from the link text alone, or from link text plus context.
• Focus visible: any component that receives keyboard focus must have a visible focus indicator.

Real-world example

A financial services portal requires users to complete a loan application. A keyboard accessibility audit finds: the custom date picker widget receives focus but cannot be operated with the keyboard (Guideline 2.1 failure); the session expires after 15 minutes with no warning and no ability to extend it (Guideline 2.2 failure); a promotional banner animates continuously with no pause control (Guideline 2.2 and potentially 2.3 concern); and no skip navigation link exists, forcing screen reader users to tab through 47 navigation links on every page (Guideline 2.4 failure). Each is a distinct, independently fixable Operable failure.