WCAG 3.2.5: Change on Request
Nothing disorients a user faster than a page that acts on its own — a redirect mid-read, a popup stealing focus, a form that submits because you touched a dropdown. This criterion states the whole philosophy of predictable design in one line: the context changes only when the user asks it to — or the user can turn the automatic behavior off.
The success criterion, in full
Changes of context are initiated only by user request or a mechanism is available to turn off such changes.
Two routes to conformance: make every context change user-initiated, or — where automation is genuinely valuable, like live-updating data — give the user an accessible switch to disable it.
Who this helps
Screen reader users
A screen reader narrates one place at a time. When the page swaps underneath — a redirect, a focus jump, a refreshed region — the narration is yanked to somewhere new with no explanation, and the user must rebuild their mental map from scratch.
Screen magnifier users
Someone viewing the page at 400% sees a small window onto it. An unrequested change happening outside that window is simply invisible — the page appears to have transformed by magic.
People with cognitive disabilities
Unexpected changes break concentration and can be genuinely distressing. Predictability — the page does what I asked, and only that — is a core cognitive accessibility principle.
People who need more time
Auto-refresh and timed redirects assume everyone reads at the same speed. Users with motor or reading disabilities lose their place, their form input, or the content itself when the timer fires first.
What counts as a change of context
WCAG defines a change of context as a major change that, made without the user’s awareness, can disorient them. Four categories:
Change of viewport
Opening a new window or tab, launching another application, or jumping the scroll position substantially.
Change of focus
Moving keyboard focus somewhere the user did not put it — into a dialog, onto a different field, back to the top of the page.
Navigation
Loading a different page: redirects, auto-submitting forms, links followed by script rather than by click.
Content that changes meaning
Replacing or rearranging the main content so the page effectively becomes a different page — not minor updates like an expanding accordion.
A user requestis an explicit, intentional action whose purpose is that change: activating a link or button, submitting a form via its submit control, choosing “open in new tab.” Merely focusing an element, typing into a field, or selecting an option in a dropdown is not a request to navigate — those are settings, and acting on them is exactly what this criterion prohibits.
The escape hatch: where automatic changes are central to the experience (live dashboards, auction pages, transit boards), provide an accessible mechanism — a pause button, a preference, a setting — that turns the automatic updates off. There are no other exceptions.
Pass and fail examples
✓ Passes 3.2.5
- A country selector with an explicit “Go” button — the dropdown itself changes nothing.
- A moved page handled by an HTTP 301 server-side redirect — the user never experiences a mid-page jump.
- A live scoreboard that auto-updates but has a prominent, accessible “Pause updates” toggle.
- A PDF link labelled “Annual report (PDF, opens in new window)” — the new viewport is part of what the user knowingly requested.
- A dialog that opens — and moves focus — only when the user clicks the button that summons it.
✗ Fails 3.2.5
<meta http-equiv="refresh">redirecting or reloading the page on a timer with no off switch.- A language dropdown that navigates the instant an option is selected (onchange submit).
- A newsletter modal that opens by itself after eight seconds and steals keyboard focus.
- A news homepage that silently reloads every 60 seconds, losing the reader’s scroll position.
- A carousel whose rotation replaces the page’s main content region with no pause control.
Code examples
Select menus: add a real submit control
Selecting an option is adjusting a setting, not requesting navigation. Keyboard users who arrow through options in an onchange-submitting select are ripped away on the very first arrow press.
<!-- ✗ Navigates the moment an option is chosen -->
<select onchange="location = this.value">
<option value="/en">English</option>
<option value="/fr">Français</option>
</select>
<!-- ✓ The user requests the change explicitly -->
<form action="/set-language" method="get">
<label for="lang">Language</label>
<select id="lang" name="lang">
<option value="en">English</option>
<option value="fr">Français</option>
</select>
<button type="submit">Apply</button>
</form>Redirects: do them server-side, or hand the user a link
<!-- ✗ Timed client-side redirect: a context change on a timer -->
<meta http-equiv="refresh" content="5;url=https://example.com/new-home">
<!-- ✓ Server-side (Next.js): the user never sees an intermediate page -->
// next.config.js
async redirects() {
return [
{ source: "/old-home", destination: "/new-home", permanent: true },
]
}
<!-- ✓ Or let the user initiate it -->
<p>This page has moved.
<a href="/new-home">Continue to the new page</a></p>Live updates with an off switch
When automatic updating is the feature, the pause mechanism is what earns conformance — make it visible, keyboard-operable, and honest.
<button type="button" aria-pressed="false" id="pause-updates">
Pause automatic updates
</button>
<div id="scores" aria-live="polite">…</div>
<script>
let timer = setInterval(refreshScores, 30000)
const btn = document.getElementById("pause-updates")
btn.addEventListener("click", () => {
const paused = btn.getAttribute("aria-pressed") === "true"
btn.setAttribute("aria-pressed", String(!paused))
btn.textContent = paused
? "Pause automatic updates"
: "Resume automatic updates"
if (paused) timer = setInterval(refreshScores, 30000)
else clearInterval(timer)
})
</script>Common failures
- Timed client-side redirects (meta refresh or setTimeout + location) that move the user with no action on their part and no way to opt out.
- Pages that auto-refresh on an interval, discarding scroll position, focus, and half-typed form input.
- Select menus, radio groups, or checkboxes that submit a form or navigate as a side effect of being set.
- Popups, modals, chat widgets, and cookie walls that open unprompted and capture keyboard focus.
- Opening new windows on page load or on a timer, rather than in response to an informed user action.
- Focus being moved by script when the user did not trigger anything — e.g. yanking focus to an error summary while the user is still typing.
- Single-page apps that replace the main content region in response to background events (websocket pushes) with neither user request nor a disable mechanism.
How to test for 3.2.5
- 1
Load the page and wait — touch nothing
Sit on the page for a few minutes. Watch for redirects, reloads, popups, focus movement, or the main content rearranging itself. Any context change during this idle period was, by definition, not user-requested.
- 2
Grep for the usual suspects
Search the source for meta http-equiv="refresh", window.open outside click handlers, location assignments inside setTimeout/setInterval, and submit() or navigation calls inside change/focus/blur handlers.
- 3
Operate every form control by keyboard
Tab to each select, radio group, and checkbox and change its value with arrow keys and Space. The page must not navigate, submit, open windows, or move focus as you do. Only activating an explicit submit control may cause the change.
- 4
Follow links and buttons, watching the viewport
Confirm windows and tabs open only from explicit activation, and that anything opening a new viewport says so in its accessible name. Dialogs may move focus only as the direct result of the user summoning them.
- 5
Hunt for the off switch on anything automatic
Where content legitimately auto-updates, verify a mechanism exists to turn it off, that it is discoverable near the updating content, keyboard-accessible, and that it genuinely stops the context changes.
Automated tools flag meta refresh but little else here — the rest is behavioral testing. Record what you find in your WCAG 2.2 checklist.
Relationship to 3.2.1 and 3.2.2
Guideline 3.2 Predictable escalates in three steps. 3.2.1 On Focus (A) forbids context changes when a component merely receives focus. 3.2.2 On Input (A) forbids them when a setting is changed — unless the user was advised of the behavior beforehand. 3.2.5 (AAA) closes every remaining gap: it covers changes triggered by anything— timers, page load, background events — and drops 3.2.2’s advance-warning loophole. A flow that passes 3.2.5 automatically passes both Level A siblings.
The timing dimension connects to Guideline 2.2: 2.2.1 Timing Adjustable (A) governs time limits (including redirect delays), and 2.2.2 Pause, Stop, Hide (A) covers moving and auto-updating content. An auto-refreshing page frequently fails all three at once — and one “pause updates” control frequently fixes all three at once.
Frequently asked questions
What does WCAG 3.2.5 Change on Request require?
It requires that changes of context — navigating to a new page, opening a new window, moving focus, or significantly rearranging the content — are initiated only by an explicit user request, or that a mechanism is available to turn such automatic changes off. It is a Level AAA success criterion under Guideline 3.2 Predictable. In short: the page changes when the user asks it to, not when a timer, a script, or an incidental interaction decides.
What exactly counts as a 'change of context'?
WCAG defines it as a major change in the content of the page that, if made without user awareness, can disorient users. The defined categories are: change of user agent (e.g. launching another application), change of viewport (new window or tab, or a significant scroll/jump), change of focus, and changes of content that alter the meaning of the page (such as replacing the main content region). Ordinary content updates — expanding an accordion, showing a validation message, updating a live region — are not changes of context.
How is 3.2.5 different from 3.2.1 On Focus and 3.2.2 On Input?
3.2.1 (A) says receiving focus must not trigger a change of context. 3.2.2 (A) says changing a setting (typing, selecting an option) must not trigger one unless the user was warned beforehand. 3.2.5 (AAA) generalizes both and removes the warning loophole: no context change from any cause — timers, focus, input, page load — unless the user explicitly requested it or can switch the behavior off. A select that submits on change with advance warning passes 3.2.2 but still fails 3.2.5.
Do automatic redirects fail 3.2.5?
Client-side timed redirects do — a page that waits five seconds and then sends you elsewhere is a context change nobody requested. The conforming pattern is either a server-side redirect (instant, before the page renders, so the user never experiences a change) or a page that presents a link the user activates themselves. The same logic applies to auto-refresh: use server-side technologies or let the user request the update, rather than reloading on a timer they cannot stop.
Can I still open links in a new window or tab under 3.2.5?
Yes — when the user is the one requesting it. Clicking a link is a user request; the debate is whether the user knows the request includes a new window. Best practice is to open in the same tab by default and, where a new window is genuinely justified, say so in the link's accessible name ('opens in new window'). A new window that opens spontaneously — on page load, on a timer, or as an advertising popup — is a clear failure.
How do 'turn it off' mechanisms satisfy 3.2.5?
The criterion offers an alternative to strict user-initiation: a mechanism to disable the automatic changes. Examples: a live sports score page that auto-refreshes but offers a visible 'Pause automatic updates' toggle; a kiosk flow with auto-advance that can be switched to manual; a preference that stops articles from auto-loading the next story. The mechanism must be easy to find and itself accessible — burying the switch three menus deep defeats the purpose.
Related Success Criteria
When a component receives focus, it does not initiate a change of context.
Changing settings of a component does not automatically cause context changes.
Navigational mechanisms are repeated in the same relative order.
Components with the same functionality are identified consistently.
Help mechanisms appear in the same relative order across pages.