WCAG Operable

Operable is the second WCAG principle. It means users can drive the interface with whatever input they have, such as a keyboard on its own, voice control, or a switch. AI interfaces add new controls and new timing problems, and both are easy to get wrong.

Key points

Operable means users can drive the interface with any input, including a keyboard on its own.
Every AI control, such as stop, regenerate, copy, and rating, must be keyboard reachable and operable.
Generated links, buttons, and files must be real, focusable elements, not text that only looks like them.
Streaming output and agents need a clear, keyboard-operable way to stop or interrupt.
Handle focus with care when new content streams in, and never trap it or yank it to the top.

Keyboard access

Every control has to work with a keyboard and let you move away again without a trap, under criteria 2.1.1 and 2.1.2. AI interfaces are full of new controls, such as stop, regenerate, copy, and the thumbs up or thumbs down rating. These are often custom widgets that were never tested without a mouse. Drive the whole turn with the keyboard alone, from typing the prompt to acting on the answer, and fix anything you cannot reach or operate.

Generated results must be real controls

A generated result is only usable if it is a real, focusable element. One blind user reported an AI tool that showed the download for a file it had created as plain text rather than a real link. The file could not be reached at all with a screen reader. As they put it, if a blind user cannot access a file, it does not exist for them. When the model produces links, buttons, or files, render them as links, buttons, and files, not as text that looks the part.

Timing

AI sessions can time out and responses can take a while to arrive. Under criterion 2.2.1, do not impose time limits that a user cannot turn off, extend, or adjust. Someone who reads slowly, composes with a switch, or steps away to think needs the answer to still be there when they return. Be especially careful with session timeouts that discard a long conversation.

Stop and interrupt

Streaming output and agents both need a clear way to stop, and that control has to be keyboard-operable. A user must be able to halt a long response, or stop an action being taken on their behalf, without reaching for a mouse. This matters most when the system is acting on its own. See Agentic actions.

Moving through long output and managing focus

Long answers need structure so a user can jump through them, which ties back to headings and lists under Perceivable. Focus also has to be handled with care, under criterion 2.4.3. When new content streams in, do not throw focus to the top of the page or trap it inside the growing response. The safest default is to leave focus where the user put it and announce new content through a live region, moving focus only when the user asked for it. See Dynamic and streaming output.

Motion and auto-updating content

If output animates, auto-scrolls, or updates on its own, give the user a way to pause or stop it, under criterion 2.2.2. Constant motion is hard for many people to read and can be disabling for some.

Audience: Engineer

Two areas cause most Operable bugs in AI interfaces.

Focus management during streaming. Decide on purpose where focus goes when a response starts and ends, and test it with a keyboard and a screen reader rather than assuming.
The stop control. Wire a real, labeled, keyboard-reachable stop button to actually cancel the request, and make sure it is reachable while the response is still streaming, not only after it finishes.

Audience: Self-advocate

A quick way to feel whether an AI tool is operable is to unplug the mouse. Can you send a prompt, stop a runaway answer, move through a long response, and open or download what it made, using only the keyboard? The download-as-plain-text failure above is the kind of thing that looks fine to a sighted tester and is a total blocker for a screen reader user.

Audience: Product Manager

Make interruptibility an explicit requirement, not a nice-to-have. Any feature that streams output or takes actions needs a stop or undo that works for everyone, including keyboard and screen reader users. Writing this into acceptance criteria early is far cheaper than retrofitting it after a user cannot cancel something that cost them money or time.