WCAG 3.2.5: Change on Request
Introduction to WCAG 3.2.5: Change on Request
WCAG 3.2.5, titled “Change on Request,” is a Level AA success criterion under the broader guideline 3.2 “Predictable.” This criterion states that “Changes of context should only occur when initiated by the user or a mechanism is provided to turn such changes off.” In essence, it aims to prevent unexpected and automatic changes to a web page’s content, layout, or destination without explicit user action.
The primary goal is to maintain user control and predictability within the browsing experience. When a web page or application changes its context unexpectedly, it can be disorienting and disruptive, particularly for users with certain disabilities. This criterion ensures that users are always in command of their interaction with the content, fostering a more stable and accessible digital environment.
Why WCAG 3.2.5 Matters: Accessibility Impact
Unexpected changes of context can create significant barriers for various user groups, hindering their ability to navigate and understand web content effectively. This criterion is vital for promoting a predictable and user-friendly experience for everyone.
User Groups Affected
- Users with Cognitive Disabilities: Individuals with cognitive, neurological, or learning disabilities (e.g., ADHD, autism, dyslexia) may find unexpected changes highly disorienting. They can lose their place, become confused, or struggle to regain focus, making it difficult to complete tasks.
- Users with Low Vision: Users who rely on screen magnifiers or limited viewports may only see a small portion of the page at a time. An unexpected change of context can cause them to lose their visual anchor, making it challenging to locate new content or understand what has happened.
- Users of Screen Readers and Assistive Technologies: When content or focus shifts automatically, screen readers may not announce the change clearly or may read content out of sequence, leading to confusion. Users may not be aware that a change has occurred or where to find the new information.
- Users with Motor Disabilities: Individuals who use alternative input devices (e.g., switch devices, head pointers) or have limited motor control may find unexpected changes particularly problematic. If a page automatically refreshes or redirects, they might not have enough time or precise control to interact with the content before it changes, potentially losing data or progress.
- Anyone in a Distracting Environment: Even users without disabilities can be frustrated and disoriented by unexpected changes, especially if they are multitasking or in a busy environment.
Impact on User Experience
Beyond specific user groups, unexpected context changes negatively impact the overall user experience by:
- Causing Disorientation: Users can lose their sense of location within the website, making navigation difficult.
- Reducing Control: Users feel a loss of control over their interaction, leading to frustration and reduced trust in the website.
- Increasing Cognitive Load: Users have to spend extra mental effort to re-orient themselves, diverting attention from the task at hand.
- Interrupting Tasks: Automatic changes can interrupt an ongoing task, potentially causing users to lose unsaved data or progress.
- Triggering Motion Sickness: For some individuals, rapid or unexpected visual changes can trigger motion sickness or vertigo.
WCAG 3.2.5 Success Criteria and Requirements
WCAG 3.2.5 is a Level AA success criterion. To understand its requirements fully, it’s crucial to define what constitutes a “change of context.”
Definition of “Change of Context” (from WCAG Glossary)
A change of context refers to major changes in the content of the Web page that, if made without the user being aware, can disorient users who are not able to see the entire page at one time. Changes of context include changes of:
- User Agent (e.g., launching a new browser window)
- Viewport (e.g., scrolling to a new location, resizing the window in a way that significantly changes layout)
- Focus (e.g., moving the keyboard focus to a different element on the page)
- Content that changes the meaning of the Web page (e.g., navigating to a new page, opening a modal dialog that takes over the screen and is unrelated to the user’s current task).
It is important to note that not all changes to content are considered a change of context. Small, localized updates (e.g., updating a stock ticker, a weather widget, or a shopping cart item count) are generally not considered a change of context as long as they do not significantly alter the page’s overall meaning or layout and are predictable.
Key Requirements
- User-Initiated: Any change of context must be the direct result of a user’s explicit action (e.g., clicking a button, submitting a form, activating a link).
- User-Controlled Mechanism: If there’s a feature that might cause a change of context automatically (e.g., an auto-refreshing page, a timer that redirects), there must be a mechanism provided for the user to turn off or adjust this automatic behavior.
- Predictable Changes: Even when user-initiated, changes should be predictable in their outcome. For example, clicking a navigation link should take the user to the linked page, not a random page.
Practical Guidelines for Compliance
To comply with WCAG 3.2.5, developers and content creators should follow these practical guidelines:
User-Initiated Actions
- Buttons and Links: Ensure that navigation, form submissions, and other significant actions are triggered by explicit user interaction with standard interactive elements like buttons (
<button>) or links (<a>). - Form Submissions: Forms should only submit when the user clicks a submit button, presses Enter in a single-line text field, or explicitly triggers the submission. Avoid automatic form submission on input changes.
- User Selection: If a change of context occurs based on a user’s selection (e.g., from a dropdown menu), ensure the change only happens after the user has explicitly confirmed their choice (e.g., by clicking a “Go” button) or that the change is clearly announced and expected.
Avoid Automatic Redirections and Refreshes
- Client-side Redirects: Do not use JavaScript to automatically redirect users to a new page after a set time.
- Meta Refreshes: Avoid using the
<meta http-equiv="refresh">tag to automatically refresh the page or redirect to a new URL. - AJAX-driven Content Updates: Be cautious with AJAX updates. While not all AJAX updates are a change of context, if a significant portion of the page’s content or its entire meaning changes without explicit user initiation, it violates this criterion. For instance, automatically loading new search results without a user pressing “search” could be problematic.
Provide Clear User Feedback
- Even for user-initiated changes, provide clear visual and programmatic feedback that a change is occurring or has occurred (e.g., focus management, live region announcements for dynamic content). This helps users understand what happened and where to focus next.
Modals and Overlays
- Modal dialogs or overlays that obscure the main content and require user interaction before proceeding are acceptable if they are directly related to a user’s previous action (e.g., a confirmation dialog after clicking “delete,” a login form triggered by clicking “sign in”). However, unsolicited pop-ups or auto-opening modals are typically a violation.
Examples of Correct and Incorrect Implementations
Correct Implementation: User-Triggered Navigation
The user explicitly clicks a link to navigate to a new page.
<nav>
<ul>
<li><a href="/products">View Products</a></li>
<li><a href="/about">About Us</a></li>
</ul>
</nav>
Incorrect Implementation: Automatic Page Reload/Redirection
The page automatically reloads or redirects after a set time without user action.
<!-- This is an accessibility violation -->
<meta http-equiv="refresh" content="5;url=http://example.com/new-page">
<!-- Or via JavaScript -->
<script>
// This will redirect the user after 5 seconds automatically
setTimeout(function() {
window.location.href = 'http://example.com/another-page';
}, 5000);
</script>
Correct Implementation: User-Submitted Form
A form only submits after the user clicks the submit button.
<form action="/search" method="get">
<label for="query">Search:</label>
<input type="text" id="query" name="q">
<button type="submit">Go</button>
</form>
Incorrect Implementation: Auto-Submitting Form on Input Change
The form submits automatically whenever the user types or makes a selection, without an explicit submit action.
<!-- This is an accessibility violation -->
<form action="/filter-results" method="get" id="filterForm">
<label for="category">Filter by Category:</label>
<select id="category" name="cat" onchange="document.getElementById('filterForm').submit();">
<option value="all">All</option>
<option value="electronics">Electronics</option>
<option value="books">Books</option>
</select>
</form>
Correction for the above: To make the incorrect example compliant, the onchange event should trigger a JavaScript function that updates the results *without* submitting the form and thus changing the entire page context, or a ‘Submit’ button should be added which the user must explicitly click after making a selection.
Correct Implementation: User-Initiated Sorting/Filtering
Dynamic updates to a list or table based on user selection, where the context (the overall page) does not change significantly, and the user initiated the action.
<!-- HTML -->
<label for="sortOrder">Sort by:</label>
<select id="sortOrder">
<option value="asc">Price: Low to High</option>
<option value="desc">Price: High to Low</option>
</select>
<ul id="product-list">
<li>Product A ($10)</li>
<li>Product B ($20)</li>
</ul>
<!-- JavaScript (simplified for demonstration) -->
<script>
document.getElementById('sortOrder').addEventListener('change', function() {
const order = this.value;
// In a real application, you'd fetch data or re-sort the existing list.
// This change is localized and user-initiated, not a 'change of context'.
console.log('Sorting products:', order);
// Example: Dynamically reorder list items via JS/DOM manipulation
const list = document.getElementById('product-list');
Array.from(list.children)
.sort((a, b) => {
const priceA = parseFloat(a.textContent.match(/$(d+)/)[1]);
const priceB = parseFloat(b.textContent.match(/$(d+)/)[1]);
return order === 'asc' ? priceA - priceB : priceB - priceA;
})
.forEach(item => list.appendChild(item));
});
</script>
Best Practices and Common Pitfalls
Best Practices
- Prioritize User Control: Always design with the user in mind, ensuring they are the drivers of navigation and significant content changes.
- Clear and Consistent UI: Use familiar UI patterns for interactive elements. Buttons should look like buttons, and links like links.
- Informative Feedback: When dynamic content updates occur (even if not a change of context), provide visual cues (e.g., loading spinners) and programmatic announcements (e.g., using `aria-live` regions for screen readers) to inform users of changes.
- Avoid Time-Based Changes: Steer clear of any automatic, time-based redirects, refreshes, or content changes unless a user-controlled mechanism to disable them is explicitly provided.
- Test with Assistive Technologies: Regularly test your website or application with screen readers and other assistive technologies to catch any unexpected behaviors caused by dynamic content.
Common Pitfalls
- Auto-Play Media or Carousels: While not always a ‘change of context’ in the WCAG definition, auto-playing media or automatically advancing carousels can be disorienting. Ensure users can pause, stop, or navigate them manually. (Note: WCAG 2.2.2 Pause, Stop, Hide also covers this).
- Session Timeouts without Warning: Automatically logging a user out or redirecting them after a session timeout without a prior warning and option to extend the session is a violation.
- Unannounced AJAX Updates: Fetching and displaying new content via AJAX without user initiation or without clear feedback that something has changed can disorient users, especially those using screen magnifiers or screen readers.
- Focus Management Issues: When a user initiates a change (e.g., opens a modal), ensure that keyboard focus is properly managed and moved to the new content, and returned appropriately when the content is dismissed.
Further Resources
For the most authoritative and detailed information, always refer to the official WCAG guidelines: