In the previous lesson we made sure content can be perceived. But perceiving is not enough: once Lucía (limited mobility, navigates with the keyboard only) sees Cursalia's catalog filter, she has to be able to open it, move through its options, and activate one without touching the mouse. The second POUR principle, Operable, requires that all interface components and navigation be operable. It covers the keyboard, timing, seizures, navigation, and input modalities (pointer, gestures, motion). It is the principle that most closely protects Lucía, but also Marta, who operates with the keyboard guided by her reader, and anyone using a switch device or voice control.

1. What the Operable principle requires
2. Guideline 2.1: Keyboard Accessible
3. Guideline 2.2: Enough Time
4. Guideline 2.3: Seizures and Physical Reactions
5. Guideline 2.4: Navigable
6. Guideline 2.5: Input Modalities
7. Success criteria summary table
8. Common mistakes and tips
9. Exercises
10. Conclusion

Operable means that anything you can do with the mouse you can also do another way, primarily with the keyboard, and that navigation is predictable: visible focus, logical order, enough time, and reachable targets. Five guidelines structure it.

All functionality must be available from the keyboard.

• 2.1.1 Keyboard (A): every function can be used with the keyboard (Tab, Enter, Space, arrows). If Cursalia's filter only opens with a mouse click, Lucía is locked out.
• 2.1.2 No Keyboard Trap (A): focus must be able to move into and out of any component. An enrollment modal that traps Tab inside forever is a "trap": Lucía cannot escape.
• 2.1.4 Character Key Shortcuts (A): if single-key shortcuts exist (e.g. "b" to search), they must be able to be turned off, remapped, or made to require focus; otherwise another user's voice control triggers them by accident.

The actual construction of keyboard-operable widgets (menus, dropdowns, modals) is detailed in Module 5: JS Widgets / Keyboard. Here we set the requirement.

Give users the time they need to read and use content.

• 2.2.1 Timing Adjustable (A): if there is a time limit (a session that expires, a timed quiz), the user must be able to turn it off, adjust it, or extend it. Hugo (ADHD) needs more time on a test.
• 2.2.2 Pause, Stop, Hide (A): any content that moves, blinks, or updates on its own (a carousel of featured courses on the landing page) must be pausable. Constant motion distracts Hugo and makes reading harder for Sofía.

• 2.3.1 Three Flashes or Below Threshold (A): nothing may flash more than three times per second (or must stay below the safe thresholds). A Cursalia promo banner with intense flashing could trigger a seizure in people with photosensitive epilepsy.

Help users navigate, find content, and know where they are.

• 2.4.1 Bypass Blocks (A): offer a skip link ("Skip to content") so users do not have to tab through the header and menu on every page. Lucía appreciates it on every load.
• 2.4.2 Page Titled (A): every page/view has a descriptive <title>. In the SPA, it must be updated when the view changes.
• 2.4.3 Focus Order (A): the tab order follows a logical flow consistent with meaning.
• 2.4.4 Link Purpose (In Context) (A): the link text must make its destination clear. Ten identical "Read more" links are useless; "Read more about Web Accessibility" works.
• 2.4.6 Headings and Labels (AA): descriptive headings and labels. Marta navigates the student dashboard by jumping through headings; if they say "Section 1", they give her no bearings.
• 2.4.7 Focus Visible (AA): the focused element must have a visible indicator. Removing the outline with no replacement leaves Lucía with no idea where she is.
• 2.4.11 Focus Not Obscured (Minimum) (AA) — new in WCAG 2.2: the focused element must not be entirely hidden by other content (a fixed bar, a cookie banner). If focus moves behind Cursalia's sticky header, Lucía cannot see it.

The design of the focus indicator and keyboard navigation in widgets is implemented in Module 5.

Make it easier to use with different devices, beyond the keyboard (touch, pointer, motion).

• 2.5.1 Pointer Gestures (A): any action that uses multipoint or path-based gestures (swiping the carousel) must also have a single-pointer alternative (previous/next buttons).
• 2.5.2 Pointer Cancellation (A): an action must not fire on mousedown; it must be cancelable by releasing outside. This prevents accidental activations, useful for motor tremor.
• 2.5.3 Label in Name (A): a control's accessible name must include its visible text. If the button reads "Enroll" but its name for assistive technology is "submit-form", voice control saying "click Enroll" fails.
• 2.5.4 Motion Actuation (A): if something is triggered by moving or shaking the device, there must be an interface alternative and the ability to turn it off.
• 2.5.7 Dragging Movements (AA) — new in 2.2: any drag action (reordering lessons on the dashboard) needs a single-click alternative. Lucía does not drag.
• 2.5.8 Target Size (Minimum) (AA) — new in 2.2: touch targets must be at least 24×24 px (with spacing exceptions). Tiny filter buttons are hard to hit with a tremor or on mobile.

• Removing the focus outline "because it's ugly". This is the number-one cause of failing 2.4.7. If you dislike the default style, redesign it, do not delete it.
• Modals that trap focus (2.1.2) or lose it on close. Focus must be able to leave and return to a logical point.
• Fixed headers that cover the focused element (2.4.11). Very common with position: sticky; you must reserve space or offset the scroll.
• Relying on the link's title or on color alone for its purpose. 2.4.4 requires that the link text be understandable.
• Tip: run the "unplugged mouse test". Put the mouse away and go through an entire Cursalia surface using only Tab, Shift+Tab, Enter, Space, and arrows. If you get stuck or lose focus, you have an Operable failure.

Exercise 1. The catalog's dropdown filter opens and closes only with a click; its options are selected with the mouse. List at least two criteria that are probably violated and what each one requires.

Exercise 2. In the student dashboard, lessons are reordered by dragging them with the mouse. Which WCAG 2.2 criterion applies, and what is the minimum alternative required for Lucía?

Exercise 3. The "Enroll" button shows that text, but its accessible name (internal label) is "cta-1". A voice-control user says "click Enroll" and nothing happens. Which criterion fails and what does it require?

Solution 1. At least: 2.1.1 Keyboard (A) —all of the filter's functionality must be operable with the keyboard— and 2.4.7 Focus Visible (AA) if you cannot see where focus is while going through it. 2.4.3 Focus Order (A) may also apply if, once opened, the tab order is inconsistent. The conceptual fix: the dropdown must open, be traversed, and be activated with the keyboard, with visible focus (implementation in Module 5).

Solution 2. 2.5.7 Dragging Movements (AA), new in WCAG 2.2 applies. It requires offering an alternative that does not require dragging, for example "move up/down" buttons or a menu with positions, activatable with a single click or with the keyboard.

Solution 3. 2.5.3 Label in Name (A) fails: the control's accessible name must contain the visible text ("Enroll"). That way, when the voice user names what they see, the assistive technology finds it. (The accessible name is implemented in Module 4.)

The Operable principle requires that the entire interface be operable without a mouse: keyboard with no traps, enough time, no dangerous flashing, navigation with visible and ordered focus, and input targets reachable by pointer, gesture, or motion. WCAG 2.2 reinforces this with new criteria (2.4.11, 2.5.7, 2.5.8) closely tied to Lucía's real-world use. We can now perceive and operate; what remains is for the person to understand what is happening: that the language is declared, that the interface is predictable, and that the enrollment form's errors are explained and can be corrected. That is the Understandable principle, which we tackle in lesson 03-03.