WCAG Operable – Principle 2 of the Web Content Accessibility Guidelines

WCAG Operable is the second of the four WCAG core principles and ensures that all users can actually operate the interface and navigation of web content – regardless of whether they use a mouse, navigate exclusively by keyboard, or rely on assistive technologies such as screen readers. Web content and functions that can only be operated with a mouse exclude a significant proportion of people from digital participation.

The Operable principle is part of the POUR framework of the WCAG – Perceivable, Operable, Understandable, Robust. It builds directly on the first principle: WCAG Perceivable ensures that content can be sensed; Operable ensures that users can then act on it. A comprehensive introduction to WCAG 2.2 is available on the SiteCockpit insights page.

For organisations running digital products, the Operable principle has direct legal implications. Under the European Accessibility Act (EAA) and the German Accessibility Strengthening Act (BFSG), WCAG AA has been mandatory for large parts of the digital market since 28 June 2025. All Operable success criteria at conformance levels A and AA are therefore the legal minimum – non-compliance can result in legal warnings and fines of up to €100,000.

WCAG Operable: The Five Guidelines Explained

The Operable principle is structured around five guidelines, each containing several success criteria. Each guideline addresses a different dimension of the central question: can all users interact with this web content and its functions?

• 1 Guideline 2.1 – Keyboard Accessible: All functions of a website must be operable by keyboard – without requiring a mouse. Users who cannot use a mouse for motor reasons navigate exclusively by keyboard or keyboard-equivalent input devices. Any function reachable only by mouse click is inaccessible to this group of users.
• 2 Guideline 2.2 – Enough Time: Users must have sufficient time to read, understand and use content and functions. Time limits must be extendable, pausable or deactivatable. Automatically updating or expiring content must not exclude users from processes without adequate warning.
• 3 Guideline 2.3 – Seizures and Physical Reactions: Content must not trigger seizures or physical reactions. Flashing or flickering content occurring more than three times per second can trigger epileptic seizures in people with photosensitivity and must be strictly avoided.
• 4 Guideline 2.4 – Navigable: Users must be able to navigate through web content and determine their current location. This encompasses skip links, descriptive page titles, a logical focus order, meaningful link text and consistent navigation. A clearly defined structure is critical for screen reader users to maintain orientation.
• 5 Guideline 2.5 – Input Modalities: Functions must be operable through input methods beyond keyboard and mouse – including touchscreen, voice input and switch access. Gestures must not be the only way to trigger a function; there must always be an adaptable alternative available.

WCAG Operable: Key Success Criteria with Reference Numbers

The Operable guidelines are operationalised through concrete success criteria. For implementing WCAG AA – the legal minimum standard – the following criteria are most relevant in practice. A detailed overview of all conformance levels is available in the WCAG AA article.

• ✓ 2.1.1 Keyboard (Level A): All functionality must be operable via keyboard. No user must be excluded from a function solely because they cannot use a mouse. The most frequently violated Operable criterion in practice.
• ✓ 2.1.2 No Keyboard Trap (Level A): Users must not become trapped within a component of the page (e.g. a modal dialog) from which they cannot escape by keyboard. Keyboard traps are among the most severe barriers for screen reader users.
• ✓ 2.2.1 Timing Adjustable (Level A): Time limits must be extendable (at least 10× the default time) or deactivatable. Applies, for example, to session timeouts in online banking or e-commerce checkouts.
• ✓ 2.3.1 Three Flashes or Below Threshold (Level A): Content must not flash more than three times per second. Content exceeding this threshold must be removed or made safe to prevent seizures.
• ✓ 2.4.1 Bypass Blocks (Level A): Users must be able to bypass repeated navigation blocks – typically via a skip link "Skip to main content" at the top of the page. Critical for keyboard and screen reader users who would otherwise have to navigate through the entire header on every page.
• ✓ 2.4.2 Page Titled (Level A): Every web page requires a descriptive <title> tag that clearly identifies the topic and context of the page. Screen readers announce the page title immediately on load.
• ✓ 2.4.3 Focus Order (Level A): The order in which interactive elements receive keyboard focus must be logical and meaningful – it must correspond to the visual and content structure of the page.
• ✓ 2.4.4 Link Purpose (In Context) (Level A): The purpose of each link must be determinable from the link text itself or its immediate context. Link texts such as "click here" or "read more" are inaccessible without context.
• ✓ 2.4.7 Focus Visible (Level AA): The keyboard focus indicator must be visible to users. Many websites remove the default focus outline via CSS (outline: none) without replacement – leaving keyboard users with no means of orientation.
• ✓ 2.4.11 Focus Not Obscured (Minimum) (Level AA, new in WCAG 2.2): The focused component must not be completely hidden by sticky headers, cookie banners or other overlapping content.
• ✓ 2.5.3 Label in Name (Level A): For elements with a visible label, the accessible name must contain that label – enabling voice input users to activate the element by speaking the visible label text.

WCAG Operable in Practice: Common Failures and How to Fix Them

Operable failures rank among the most frequent accessibility violations after missing text alternatives and contrast issues. Critically, many of these failures are caused by just a few lines of CSS or JavaScript and are straightforward to prevent – yet they are systematically overlooked because keyboard operability is rarely tested during development.

• ✓ Removed focus indicator: outline: none or outline: 0 in CSS removes the visible keyboard focus without replacement. Fix: define a custom focus style that meets the requirements of 2.4.7 and 2.4.11 – at minimum 3:1 contrast against the surrounding background.
• ✓ Dropdown menus not keyboard-accessible: Navigation that only works on hover is inaccessible to keyboard users. Fix: dropdown menus must be expandable and navigable by keyboard, with correct ARIA markup (aria-expanded, aria-haspopup).
• ✓ Keyboard trap in modal dialogs: Modal dialogs where focus is not managed correctly can trap keyboard users. Fix: move focus into the modal on open, return focus to the triggering element on close, and make the background inert for keyboard navigation while the modal is open.
• ✓ Non-descriptive link text: Link texts such as "here", "more" or "continue" do not describe the purpose of the link. Screen reader users who use a link list for navigation see only a list of context-free "here" links. Fix: link text must describe the destination or action – e.g. "Learn more about WCAG AA".
• ✓ Missing skip link: Without a skip link, keyboard users must tab through the entire navigation on every page before reaching the main content. Fix: implement a visible or focus-revealed skip link "Skip to main content" as the first interactive element on the page.
• ✓ Time limits without warning: Session timeouts in shops or banking applications that expire without warning and destroy entered data. Fix: warn users at least 20 seconds before expiry and provide a way to extend the session.

WCAG Operable vs. Perceivable, Understandable and Robust

Operable is the second WCAG principle in the POUR framework. It presupposes that content is perceivable and in turn creates the prerequisite for users to understand content and for technologies to process it reliably. Full WCAG conformance requires all four principles to be satisfied.

• ✓ Perceivable (Principle 1): Can users sense content? → Text alternatives, contrast, captions, semantic structure. See WCAG Perceivable.
• ✓ Operable (Principle 2): Can users interact with the interface? → Keyboard, time, avoid seizures, navigation, input modalities. This article.
• ✓ Understandable (Principle 3): Are content and operation comprehensible? → Readable language, predictable behaviour, error prevention and input assistance.
• ✓ Robust (Principle 4): Can assistive technologies reliably interpret content? → Valid HTML, ARIA markup, future-proof implementation.

In practice, the principles overlap: an interactive element with no accessible name violates both Operable (a screen reader user cannot activate it) and Robust (the assistive technology cannot determine its role and state). The POUR structure serves as a conceptual framework; WCAG conformance always requires a holistic view of all four principles and all relevant conformance levels.

Frequently Asked Questions about WCAG Operable