Unexpected changes of context can be disorienting, even when the change itself is technically correct. When pages refresh, navigate, open new windows, or replace large sections of content automatically, users may lose their place, their task, or their understanding of what just happened.
In WCAG, “context” refers to the user’s current page, focus location, task, and navigation state. When that context changes without the user’s control, the experience becomes unpredictable.
Some users rely on a stable context to stay oriented. Others need time to prepare for changes. WCAG addresses this at the highest level by requiring that major context changes happen only when users explicitly request them, or when users can turn them off.
WCAG Success Criterion
3.2.5 Change on Request (Level AAA)
Changes of context are initiated only by user request, or a mechanism is available to turn off such changes.
This is a Level AAA success criterion. It is not required for Level A or AA conformance, but it provides strong protection against disorientation and loss of control.
What WCAG Means by “Change of Context”
A change of context includes events such as:
- Navigating to a new page
- Opening a new window or tab
- Submitting a form
- Replacing significant content
- Moving focus to a different area unexpectedly
Minor changes, such as revealing additional fields or updating small portions of content, do not necessarily count as context changes unless they disrupt task flow, focus location, or user orientation.
What “User Request” Means
A user request is a clear, intentional action by the user to cause a change.
Examples include:
- Clicking a button or link
- Pressing Enter or Space to activate a control
- Explicitly choosing an option labelled “Update,” “Next,” or “Refresh”
Automatic changes triggered by time, focus, hover, or value changes are not user requests.
Plain-Language Requirements of SC 3.2.5
If your content changes context automatically, users must be able to:
- Trigger the change themselves
- Or turn the automatic behaviour off
WCAG does not ban context changes. It requires that users—not the system—decide when they happen.
How This Differs from Related Criteria
- 3.2.1 On Focus
Prevents context changes when an element merely receives focus - 3.2.2 On Input
Prevents context changes when a value is changed, unless users are warned - 3.2.5 Change on Request
Goes further: even warned or predictable changes must be user-initiated or disable-able
This is why 3.2.5 is Level AAA.
Common Situations Covered by This Criterion
This criterion applies to patterns such as:
- Auto-refreshing dashboards
- Automatically rotating slideshows
- Auto-advancing carousels
- Timed redirects
- Auto-submitting forms
- Content that changes based on system timers
Some of these may be acceptable at Level A or AA. At Level AAA, users must be given control.
Acceptable Ways to Meet This Criterion
Designs commonly meet 3.2.5 by:
- Providing an explicit control (for example, “Update now”)
- Allowing users to pause or stop automatic changes
- Respecting system or user preferences
- Offering settings to disable auto-updates
The key requirement is choice.
When users initiate a context change, focus should move predictably so users can understand what changed and continue their task without confusion.
Realistic Examples
User-initiated update
Instead of refreshing content automatically, a page includes a clearly labelled “Refresh” or “Update now” button.
The user decides when the change occurs.
Slideshow with controls
A slideshow does not auto-advance by default, or includes visible pause and play controls that work with keyboard and assistive technologies.
Automatic redirect with no user awareness
A page redirects immediately to another page without warning or user control. At Level AAA, this fails unless the redirect can be turned off or is fully user-initiated.
Important Nuance: Server-Side Redirects
In some cases, redirects occur before users perceive a page at all (for example, redirecting from an outdated URL). These may be less disruptive because users never experience the original context. However, if users can perceive the page before the redirect, the change must still meet this criterion.
Why This Matters
Blind and Low-Vision Users
Unexpected context changes can:
- Interrupt screen reader output
- Move focus without warning
- Break navigation history
Users may not realise what changed or how to recover.
Users with Cognitive Disabilities
Automatic changes can:
- Disrupt concentration
- Break task flow
- Increase confusion or anxiety
Control reduces cognitive load.
Users with Motor Impairments
Timed or automatic changes can:
- Occur before users can react
- Remove content mid-interaction
Giving control prevents task failure.
Common Failure Patterns
- Auto-refreshing content with no pause option
- Slideshows that advance automatically without controls
- Timed redirects without user consent
- Forms that submit automatically after a delay
- Content that updates based on system events alone
Even if these patterns are predictable, they still fail at Level AAA without user control.
How to Test
- Identify any content that changes without direct user activation
- Check whether users can:
- Trigger the change themselves
- Pause, stop, or disable it
- Verify controls work with:
- Keyboard navigation
- Screen readers
- Confirm preferences persist and are discoverable
If a user cannot prevent or control the change, the criterion is not met.
Rule Description
Major changes of context must occur only when users explicitly request them, or users must be provided with a reliable way to turn those changes off.
Wrapping Up
Change on Request represents the strongest form of predictability: user control. WCAG 3.2.5 does not forbid dynamic or interactive content. It requires that users, not timers, scripts, or assumptions, decide when context changes occur. While this is a Level AAA requirement, applying it reduces disorientation, prevents task loss, and makes complex interfaces safer to use.
