WCAG Operable Principle
Principle 2: Operable
User interface components and navigation must be operable. This means users must be able to operate the interface - it cannot require interaction that a user cannot perform.
Why Operability Matters
The Operable principle ensures that all users can interact with web content regardless of how they access it. Many users cannot use a mouse and rely on keyboards, switches, voice control, or other assistive technologies. Others may need more time to complete tasks or may be harmed by flashing content.
2.1 Million
Americans use wheelchairs and may rely on keyboards
3.4 Million
Americans have epilepsy (seizure risk from flashing)
15%
of adults have cognitive disabilities affecting timing
Guideline 2.1: Keyboard Accessible
Make all functionality available from a keyboard.
All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
Key Requirements:
- Tab Navigation: Users can move through all interactive elements using Tab/Shift+Tab
- Enter/Space Activation: Buttons and links can be activated with Enter or Space
- Arrow Key Navigation: Menus, tabs, and custom widgets support arrow keys
- Escape Key: Dialogs and overlays can be closed with Escape
If keyboard focus can be moved to a component using a keyboard interface, then focus can be moved away from that component using only a keyboard interface.
Common Keyboard Traps:
- Embedded videos or media players
- Third-party widgets (maps, social media embeds)
- Modal dialogs without proper focus management
- Rich text editors
- Custom form controls
Test: Tab through your entire page. Can you always move forward with Tab and backward with Shift+Tab?
If a keyboard shortcut uses only letter, number, punctuation, or symbol keys, users must be able to turn it off, remap it, or it should only be active when a component has focus.
This prevents conflicts with screen reader commands and speech input software that may interpret letters as commands.
Guideline 2.2: Enough Time
Provide users enough time to read and use content.
For each time limit set by content, at least one of the following is true:
- Turn Off: User can turn off time limit before encountering it
- Adjust: User can adjust limit to at least 10x default
- Extend: User is warned and given 20 seconds to extend with simple action, and can extend at least 10 times
Common Applications: Session timeouts, auto-advancing carousels, timed forms, auction bidding.
For moving, blinking, scrolling, or auto-updating content:
- Moving/Blinking/Scrolling: If it starts automatically, lasts more than 5 seconds, and is presented with other content, users must be able to pause, stop, or hide it
- Auto-updating: Users must be able to pause, stop, hide, or control update frequency
Applies to: News tickers, stock tickers, carousels, animated banners, auto-updating feeds.
Guideline 2.3: Seizures and Physical Reactions
Do not design content in a way that is known to cause seizures or physical reactions.
Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.
Critical Safety Issue
Flashing content can trigger seizures in people with photosensitive epilepsy. This is not just an accessibility issue - it's a safety issue. The 1997 "Pokemon Shock" incident in Japan caused seizures in nearly 700 children.
Content to Check:
- Animated GIFs and videos
- Blinking text or graphics
- Rapidly changing images
- Strobe effects
Guideline 2.4: Navigable
Provide ways to help users navigate, find content, and determine where they are.
A mechanism is available to bypass blocks of content that are repeated on multiple web pages.
- Skip navigation links
- ARIA landmarks
- Heading structure
Web pages have titles that describe topic or purpose.
- Unique, descriptive titles
- Include site name
- Most specific info first
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
The purpose of each link can be determined from the link text alone or from context.
- Avoid "click here" or "read more"
- Use descriptive link text
- Or provide context in surrounding content
Guideline 2.5: Input Modalities (WCAG 2.1)
Make it easier for users to operate functionality through various inputs beyond keyboard.
All functionality that uses multipoint or path-based gestures can be operated with a single pointer without a path-based gesture.
Example: Pinch-to-zoom must have button alternatives (+/-), swipe gestures must have arrow buttons.
For user interface components with labels that include text or images of text, the accessible name contains the visible text.
This is critical for voice control users who say visible labels to activate controls.
The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:
- Equivalent control exists elsewhere on the page
- Target is in a sentence or list (inline)
- Size is determined by user agent
- Presentation is essential
Common Operable Issues in Audits
| Issue | Prevalence | How to Fix |
|---|---|---|
| Missing focus indicators | 78% of sites | Add visible :focus styles to all interactive elements |
| Keyboard inaccessible controls | 65% of sites | Add keyboard event handlers alongside click handlers |
| Missing skip links | 52% of sites | Add "Skip to main content" link as first focusable element |
| Auto-playing media | 34% of sites | Add pause/stop controls, don't auto-play with audio |
| Session timeouts without warning | 28% of sites | Warn users before timeout, allow extension |
Testing Operable Requirements
- Unplug your mouse
- Navigate using only Tab/Shift+Tab
- Activate controls with Enter/Space
- Use arrow keys in menus/widgets
- Press Escape to close dialogs
- Verify focus is always visible
- Tab order checkers
- Focus indicator validators
- Skip link detection
- Flash detection tools (PEAT)
- Target size analyzers
Related WCAG Principles
On This Page
Related Laws
Critical Requirement
78%
of websites have missing focus indicators