Keyboard-only through a long run
A multi-minute agent run fits 2.2.2’s definition of auto-updating information, which makes the cancel control an obligation rather than a nicety — and the harder problem is how a keyboard user reaches a review gate that appears somewhere they are not.
The run has been going four minutes. The extraction agent is on its eleventh document, the progress panel is updating every second or so, and the reviewer has realised the wrong batch was selected. A mouse user moves the pointer to the Stop button and this is over.
A keyboard user presses Tab. Focus goes to a filter control, then to a column header, then into the results table, and the run banner is a sticky element at the top of the viewport that nothing in the tab sequence ever reaches, because the person who built it never had to reach it. Four minutes becomes however long the run takes.
Most teams file that as a usability complaint. It is a Level A conformance failure, and this lesson is about being able to say so with a number.
2.2.2 is two clauses, and the second one has no time limit
2.2.2 Pause, Stop, Hide, Level A is usually quoted as the blinking-content rule, which is half of it. The clause that matters here is the second one, and the normative text reads:
For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
Three conditions, all of them satisfied by a running agent. It starts automatically once you submit the batch. It is presented in parallel with the rest of the page, which is still there and still interactive. And the auto-updating is not essential to the activity: the work continues whether or not you watch it tick.
The detail that closes the usual escape route is in the Understanding document: there is no five-second exception for auto-updating. The five seconds people remember belongs to the moving, blinking and scrolling clause, and the Working Group’s reasoning for not extending it is that it “makes little sense to auto-update for a few seconds and then stop”. A four-minute run is not going to slip under a threshold that does not exist.
Where people get burned
Applying 2.2.2 to an agent run is this course’s reasoning, not the W3C’s example. The Understanding document’s own worked examples are weather data, news feeds, stock prices and auto-advancing presentations. An agent run is not among them, and no W3C document names one. What the course claims is that a long run fits the shape the clause describes — starts automatically, runs in parallel with other content, is not essential to watch — which is an argument from the criterion’s own three conditions rather than an appeal to precedent. State it that way in a finding. Somebody will eventually push back, and “here are the three conditions and here is how our run meets each” survives that conversation. “The W3C says agent runs need a cancel button” does not, because the W3C does not say that.
What the obligation actually costs you
“There is a mechanism” is doing more work in that sentence than it looks. A Stop button that exists is not a mechanism if a keyboard user cannot get to it, cannot see where they are, or cannot tell whether it worked. Four other criteria attach to the same control, and each one is a separate row in the note:
- 2.1.1 Keyboard, Level A. The control has to be operable through a keyboard interface. A sticky banner rendered outside the natural tab sequence, or worse, a
<div onClick>with notabindex, fails here as well as at 2.2.2. - 2.4.7 Focus Visible, Level AA. The user has to be able to see that the Stop button is the thing they are about to activate. This is a presence rule and nothing more — it specifies no size, thickness or contrast.
- 1.4.11 Non-text Contrast, Level AA. Where the quantification for that indicator lives: 3:1 against adjacent colours for the visual information that identifies the control and its state.
- 2.4.11 Focus Not Obscured (Minimum), Level AA — WCAG 2.2 only. A run banner pinned to the top of the viewport is exactly the element that hides a focused control scrolled up underneath it. Note the version: if the target line in your note says 2.1 AA, this criterion is not in scope and you cannot cite it. Say so rather than quietly borrowing it.
And one more that only shows up if you actually run the sequence: cancelling has to be reported. A run that stops silently leaves a screen reader user pressing Enter again on a button that no longer does anything. That is 4.1.3 Status Messages at Level AA, and the announce-on-transition pattern from the announcing-the-stream lesson covers it — one polite message, once, saying the run stopped and how far it got.
The gate that appears somewhere you are not
Now the harder half, and the half with no source at all.
Mid-run, the agent hits a document it cannot resolve and opens a review gate lower down the page. A sighted user sees it appear and moves the pointer. A keyboard user is somewhere else in the tab order — possibly above it, possibly below it, possibly inside a table they were reading — and there is no mechanism in HTML that tells them a new interactive region exists twelve stops away.
This is this course’s own observation, not a documented accessibility finding. The W3C material on keyboard interaction, the WCAG 2.1 and 2.2 criteria, and the ARIA Authoring Practices Guide were all searched for a treatment of content that becomes available at an unpredictable location during an ongoing process, and nothing addresses it. Do not attach a criterion number to the problem. The cancel-control obligation above is sourced and numbered; this is not, and mixing them would spend the credibility of the first on the second.
What the course argues for, as its own position:
- Announce it, politely, once. The gate appearing is a status message under 4.1.3 — the results of an action — and it belongs in the same transitions region as the run start and finish.
- Say where it is in the announcement. “Review needed on document 4” is a notification. “Review needed on document 4. Press R to go there” is a route. The second one costs one extra clause and removes the entire problem.
- Make the route a user action, never an automatic move. The shortcut moves focus because the user pressed it, which is a change of context the user initiated. Moving focus on your own initiative is a different decision with a different cost, and the interrupting-without-hijacking lesson is where that gets argued properly.
- Give the gate a landmark or a heading. A screen reader user navigating by heading or landmark can find a region that announces itself in the document structure. A pile of
<div>elements is unreachable by any navigation command.
Check your recall
Answer from memory — no scrolling back.
Retrieval check
Unplug your mouse. Start a run in the review gate. List every keyboard-only failure you would expect to hit before the run finishes, and give each one a number and a level.
Check your answer
The recurring set, in the order you tend to meet them:
- 2.2.2 Pause, Stop, Hide, Level A. No keyboard-reachable stop for auto-updating content that started automatically and runs in parallel with the rest of the page.
- 2.1.1 Keyboard, Level A. The stop control exists but is a click handler on a non-focusable element, so it is not operable through a keyboard interface at all.
- 2.4.7 Focus Visible, Level AA. Focus is somewhere in the run banner and there is no indicator saying where.
- 1.4.11 Non-text Contrast, Level AA. There is an indicator, and it is a 1px hairline that does not reach 3:1 against the banner behind it.
- 4.1.3 Status Messages, Level AA. The run stops and says nothing, so the only confirmation is visual.
- Reaching the mid-run review gate — no criterion. Real, severe, and unnumbered. Write it in the note as an unnumbered usability finding rather than inventing a citation for it.
If you produced categories rather than numbers, run the list again. The number is what converts a complaint into a scheduled ticket.
Hands on
Run the gate with no mouse and write what breaks
Done when: CONFORMANCE.md carries a 2.2.2 row at Level A with a runnable test and a remediation cost, every criterion in this lesson that applies to the cancel control has its own row rather than being folded into the 2.2.2 one, and the mid-run discoverability problem is recorded as an unnumbered finding that carries no criterion.
- Physically disconnect the mouse or trackpad. Not “avoid using it” — disconnect it. Every developer who has tried both reports the same thing, which is that the hand moves before the conscience does.
- Start a run long enough to work with. Try to stop it using only the keyboard, and time yourself. Record what you did, not what you would have done: the number of Tab presses, or the fact that you could not.
- Add the 2.2.2 Pause, Stop, Hide row at Level A. In the test column write the sequence you just ran, in enough detail that another engineer could reproduce it. Provenance is
human. Nothing here istool. - Give the cancel control its own rows for the criteria it touches separately: 2.1.1 at A, 2.4.7 at AA, 1.4.11 at AA, and 4.1.3 at AA for the stop confirmation. Resist writing one row that says “keyboard issues.” A row that bundles four criteria cannot be closed, because closing it requires four different fixes at four different costs.
- If the run banner can obscure a focused control, decide whether 2.4.11 is in scope by looking at your own Target line. If the target is 2.1 AA, record the behaviour under a heading that says it is outside the target version, and say which version would cover it.
- Add the mid-run gate discoverability problem under Checked by nobody or as an explicitly unnumbered usability finding. It gets a description and a cost and no criterion. Then bring the whole set into the chat — I will look for rows that bundle criteria and for a number attached to the unnumbered finding.
What this does not cover
This lesson gets a user to a control and stops. It does not decide what happens when the agent is the one that needs something: a low-confidence field, a permission, an answer it cannot proceed without. Announcing that without moving focus is a real constraint, because WCAG’s own glossary counts a change of focus as a change of context — and role="alert" and a relocated focus ring turn out to be two different decisions rather than two spellings of the same one. The interrupting-without-hijacking lesson takes that apart.
It also leaves the trace alone. Once a run has finished, its nested steps are a navigation problem rather than an announcement problem, and it is the one problem in this module the APG has already solved — which the a-trace-tree-you-can-navigate lesson uses to argue that nested disclosures were never the right shape for it.
Read this next — primary source
Understanding Success Criterion 2.2.2: Pause, Stop, HideW3C Web Accessibility Initiative — free, informative (non-normative)
Read it for the structure rather than the rule: 2.2.2 is two separate clauses that people quote as one, and the five-second exception belongs to only one of them. The Intent section is where the reasoning lives, including why the auto-updating clause deliberately has no time exemption, and the worked examples show the shape of content the Working Group had in mind. Reading those examples is also how you will see for yourself that an agent run is not among them, which is the honest starting point for applying it to one.
Stuck, curious, or think this lesson is wrong? Ask your teaching agent. The lessons are the scaffold; the conversation is where the learning gets unstuck.