WCAG 3.2.5 Change on Request: Stop Unexpected Page Changes

What This Criterion Requires

WCAG 3.2.5 requires that changes of context are initiated only by user request, or that a mechanism is available to turn off such changes. A change of context is a major shift in the content of a web page that, if made without user awareness, can disorient users who are unable to view the entire page simultaneously. This includes automatic redirects after a timer, pages that refresh at regular intervals, new windows that open without user action, and focus changes that happen automatically when a component receives input. For users who rely on screen readers, unexpected context changes can be extremely confusing because the user may not realize the page has changed around them. This criterion goes beyond the Level A requirements of 3.2.1 (On Focus) and 3.2.2 (On Input) by requiring that all context changes be user-initiated. Implementing this means replacing auto-redirects with user-activated links, providing controls to pause or stop auto-updating content, and ensuring new windows only open when users explicitly request them. Sites meeting this criterion give users full control over their browsing experience, which benefits not just users with disabilities but anyone who prefers predictable, stable interfaces.

Why It Matters

Unexpected context changes are among the most disorienting experiences on the web for people with cognitive disabilities and screen reader users. When a page automatically redirects, refreshes, or opens a new window, screen reader users lose their place and must re-orient themselves to entirely new content. Users with cognitive disabilities may not understand what happened or how to return to their previous task. Even users with low vision who have magnified the screen may miss a context change happening outside their visible viewport. Auto-refreshing news feeds or dashboards can repeatedly interrupt someone mid-sentence, while auto-advancing carousels may change content before a user with motor impairments can interact with it. In financial and medical applications, unexpected context changes can cause users to lose partially entered data, leading to frustration and abandonment. Meeting this criterion creates a predictable, user-controlled browsing experience where nothing changes unless the user explicitly requests it. This predictability is foundational to making the web truly accessible.

Common Failures and How to Fix Them

<meta http-equiv="refresh" content="5;url=/new-page">

<p>This page has moved. <a href="/new-page">Go to the new page</a>.</p>

<div class="carousel" data-auto-advance="4000">
  <div class="slide">Slide 1 content</div>
  <div class="slide">Slide 2 content</div>
</div>

<div class="carousel" role="region" aria-label="Featured content"
  aria-roledescription="carousel">
  <button aria-label="Pause auto-advance"
    onclick="toggleAutoAdvance()">Pause</button>
  <button aria-label="Previous slide">Previous</button>
  <button aria-label="Next slide">Next</button>
  <div class="slide" role="group" aria-label="1 of 3">
    Slide 1 content
  </div>
</div>

<script>
window.onload = function() {
  window.open('/special-offer', '_blank',
    'width=400,height=300');
};
</script>

<a href="/special-offer" target="_blank"
  rel="noopener noreferrer">
  View our special offer
  <span class="visually-hidden">(opens in new window)</span>
</a>

How to Test

1. Navigate through every page and monitor for automatic redirects, page refreshes, or new windows that open without user action.
2. Check for meta refresh tags in the page source that automatically redirect or reload the page.
3. Verify that all carousels, slideshows, and auto-updating content have visible pause or stop controls.
4. Test with a screen reader to confirm that no context changes occur without explicit user interaction, and that any mechanisms to control auto-changes are accessible.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

• Wordpress Accessibility Checklist
• Shopify Accessibility Checklist
• Squarespace Accessibility Checklist
• Wix Accessibility Checklist

Further Reading

• Accessible Navigation Guide
• Keyboard Navigation Testing
• Wcag Explained Plain English

Related WCAG Criteria

• WCAG 3.2.1
• WCAG 3.2.2
• WCAG 2.2.2