WCAG 3.2.5: Change on Request

What This Rule Means

WCAG 3.2.5 Change on Request is a Level AAA criterion under the Understandable principle. It states that changes of context must be initiated only by the user, not triggered automatically by the system. A "change of context" is defined in WCAG as a major change in the content of the web page that, without user awareness, can disorient users who are unable to view the entire page at once. This includes changes to the user agent (browser), viewport, focus, or content that significantly alters the meaning of the page.

Specifically, the criterion prohibits any mechanism that causes a context change without an explicit user request. This extends the requirements of 3.2.1 (On Focus) and 3.2.2 (On Input) by addressing all remaining scenarios where automatic context changes could occur — including but not limited to: auto-refreshing pages, carousels that auto-advance and navigate away, meta redirect tags with short delays, JavaScript-triggered navigation upon form field completion, and opening new windows or tabs without user instigation.

A pass under this criterion requires one of two conditions: either changes of context are only triggered by explicit, deliberate user action (such as activating a button or link), or a mechanism is provided that allows the user to turn off automatic context changes before they occur. For example, if a page auto-refreshes every 30 seconds and navigates to new content, it fails — unless a clearly labeled control exists to disable that behavior before the first refresh happens. Simply providing a warning after the fact is not sufficient.

The criterion applies broadly to all interactive and dynamic web content. Common affected elements and behaviors include: <meta http-equiv='refresh'> redirects, JavaScript's window.location or history.pushState calls triggered on timers, onchange event handlers on <select> elements that navigate to a new URL, auto-submitting forms, focus-triggered navigation, and any widget that automatically scrolls, advances slides, or changes the visible content set without user input.

An important official exception: if the change of context is in response to a setting that the user has explicitly and knowingly configured — for example, a user preference panel where the user selects "auto-refresh every minute" — the automatic behavior is permissible because the user requested it. The key distinction is whether the user made an informed, deliberate choice to enable the automatic behavior, versus encountering it unexpectedly.

Why It Matters

Unexpected context changes are among the most disorienting experiences on the web, and their impact varies significantly across different groups of users with disabilities.

For blind users relying on screen readers, a sudden page navigation or content refresh can cause the reading cursor to jump to an entirely different position on the page — or reset to the top — without any announcement. If a user is mid-sentence in a long article and the page auto-redirects to a new URL, they lose their place entirely and may not understand what happened or how to recover. Screen readers like NVDA, JAWS, and VoiceOver do not always announce page-level navigation events in a consistent or timely manner, so users may be confused about where they are and what changed.

For users with motor impairments who navigate by keyboard, head pointer, switch device, or eye-tracking technology, unexpected focus changes can be catastrophic. If focus is programmatically moved without user action — for instance, when a form auto-advances to the next field upon completing the previous one — the user may lose track of their position and be forced to laboriously re-navigate to find where the system has taken them. For users whose input devices require significant physical effort per keystroke, this re-navigation represents a real accessibility barrier.

Users with cognitive disabilities, including those with attention deficit disorders, memory impairments, or anxiety conditions, are particularly vulnerable to unexpected changes. Automatic page changes break their mental model of the interface. A user who pauses to read instructions and then finds the page has reloaded is likely to feel confused or distressed. This disruption can make it impossible to complete transactions or consume information independently.

For users with vestibular disorders, rapid and unexpected visual changes — like an auto-advancing carousel that also triggers navigation — can cause physical symptoms including dizziness and nausea. Even sighted users with no diagnosed disability benefit from predictable interfaces: research consistently shows that unexpected navigations increase error rates and task abandonment across all user groups.

A concrete real-world scenario: a Turkish e-commerce site auto-submits a product filter form the moment a user selects a value in a dropdown — navigating to a new search results URL. A keyboard-only user who is tabbing through the filters to select multiple criteria finds that selecting the first option immediately reloads the page and collapses the filter panel. They must re-open the panel, re-navigate to their starting position, and try again — potentially in a loop that makes the feature completely unusable. According to the World Health Organization, approximately 1.3 billion people worldwide live with some form of disability, and patterns like this disproportionately exclude them from digital services.

From a usability and SEO perspective, pages that auto-redirect or auto-refresh also tend to have higher bounce rates, as users who encounter unexpected behavior often leave. Search engines can also penalize unexpected redirects that differ between crawler and user sessions, making conformance with 3.2.5 aligned with good technical SEO hygiene.

Related Axe-core Rules

WCAG 3.2.5 requires manual testing because automated tools cannot reliably detect whether a context change was initiated by the user or triggered automatically. The distinction depends on understanding user intent and interaction flow, which requires human judgment. No axe-core rule directly maps to the full scope of this criterion. However, the following considerations apply to automated and semi-automated testing:

• No direct axe-core rule (manual testing required): Axe-core and Lighthouse cannot detect JavaScript-triggered navigations, auto-refreshing pages, or auto-submitting forms because these behaviors depend on runtime conditions, timing, and user interaction state that static or scripted scans cannot replicate. A scanner observing the DOM at a single point in time cannot determine whether window.location.href is being set in response to a timer or to a user click.
• Meta refresh detection (partial automation possible): Some automated tools, including older axe rules and browser extensions, can flag the presence of <meta http-equiv='refresh' content='0; url=...'> in the document head. However, axe-core does not have a dedicated production rule for this in version 4.10. Manual inspection of the page source and HTTP headers is required to verify that no automatic redirect is occurring.
• Event listener analysis (manual): Detecting onchange handlers on <select> elements that trigger navigation requires a manual code review or use of browser developer tools to inspect attached event listeners. Automated scans observe the rendered DOM but not the behavioral consequences of interacting with each element.
• Focus management verification (manual): Whether focus moves unexpectedly as a result of a system-initiated context change — rather than a user action — requires a tester to actually interact with the page and observe focus behavior in real time, using a keyboard and optionally a screen reader.

How to Test

1. Automated scan (baseline): Run axe DevTools or Lighthouse against the page to catch any flagged issues related to redirects or focus management. In Chrome DevTools, open the Lighthouse panel and run an Accessibility audit. In the axe DevTools extension, click "Analyze" and review results. Note that a clean automated result does not confirm conformance with 3.2.5 — manual testing is essential.
2. Inspect for meta refresh: Open the page in a browser, right-click and select "View Page Source," then search (Ctrl+F / Cmd+F) for http-equiv or refresh. Any <meta http-equiv='refresh'> tag with a URL or with a delay of more than 72 hours without a mechanism to disable it constitutes a failure.
3. Observe page behavior over time: Load the page and wait without interacting for 2–5 minutes. Watch for any automatic content changes, page reloads, navigation events, or new windows opening. Check the browser's address bar and tab title for changes. If any occur without your input, the criterion likely fails.
4. Test form controls and dropdowns: Using only the keyboard (Tab, Arrow keys, Enter, Space), navigate to each <select>, radio button group, or checkbox. Change values and observe whether a navigation or major content change occurs immediately upon selection — before you activate a submit button. If it does, this is a failure unless a control to disable this behavior was provided before you reached the element.
5. Test with NVDA + Firefox: Enable NVDA (Insert+Space for browse mode), navigate the page using arrow keys and Tab. Complete form interactions and note whether focus or reading position is unexpectedly relocated. Listen for announcements of page changes. If the screen reader announces a new page or the virtual cursor resets without your explicit action, this indicates a context change.
6. Test with VoiceOver + Safari (macOS/iOS): Enable VoiceOver (Cmd+F5 on Mac), navigate using VO+Arrow. Interact with controls and listen for unexpected page announcements or cursor resets. On iOS, swipe through elements and note any sudden changes in the accessibility tree structure that you did not initiate.
7. Test with JAWS + Chrome: Enable JAWS and navigate with Tab and Arrow keys. Submit forms and interact with dynamic widgets. Verify that focus and virtual cursor position remain predictable and under your control at all times.
8. Review JavaScript source: In Chrome DevTools, use the Sources panel or search (Ctrl+Shift+F) for patterns like window.location, location.href, history.pushState, setTimeout combined with navigation calls, and onchange attributes. Evaluate whether any of these are triggered by timers or system events rather than explicit user actions.
9. Check for auto-advancing carousels and sliders: Identify any carousels, slideshows, or rotating banners on the page. Verify whether they advance automatically. If they do, check whether they also trigger navigation (e.g., linking to new pages) upon auto-advance. Auto-advancing carousels that only change visible content may be addressed by 2.2.2, but if they also cause navigation they fall under 3.2.5.

How to Fix

Meta refresh redirect — Incorrect

<!-- This meta tag automatically redirects the user after 5 seconds.
     The user has no control over this navigation. -->
<head>
  <meta http-equiv='refresh' content='5; url=https://example.com/new-page'>
</head>
<body>
  <p>You will be redirected shortly...</p>
</body>

Meta refresh redirect — Correct

<!-- Remove the automatic redirect entirely.
     Provide an explicit link that the user can activate on their own terms.
     This gives users full control over when navigation occurs. -->
<head>
  <!-- No meta refresh tag -->
</head>
<body>
  <p>This page has moved. Please visit the new location:</p>
  <a href='https://example.com/new-page'>Go to the updated page</a>
</body>

Select element that auto-navigates on change — Incorrect

<!-- The onchange handler immediately navigates when the user selects a value.
     Keyboard users have no chance to review their selection before navigation. -->
<label for='category'>Choose a category:</label>
<select id='category' onchange='window.location.href = this.value'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>

Select element that auto-navigates on change — Correct

<!-- The select element no longer triggers navigation on change.
     A clearly labeled button gives the user explicit control over when to proceed.
     This pattern works for all users, including keyboard and screen reader users. -->
<label for='category'>Choose a category:</label>
<select id='category'>
  <option value=''>Select...</option>
  <option value='/electronics'>Electronics</option>
  <option value='/clothing'>Clothing</option>
  <option value='/books'>Books</option>
</select>
<button type='button' onclick='navigateToCategory()'>Go to category</button>

<script>
function navigateToCategory() {
  var select = document.getElementById('category');
  if (select.value) {
    window.location.href = select.value;
  }
}
</script>

Auto-advancing carousel that triggers navigation — Incorrect

<!-- This carousel auto-advances every 3 seconds and each slide links to a new page.
     When the slide changes automatically, clicking anywhere on it navigates unexpectedly. -->
<div id='carousel'>
  <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale'></a>
</div>
<script>
var slides = ['/promo/summer', '/promo/winter', '/promo/spring'];
var current = 0;
setInterval(function() {
  current = (current + 1) % slides.length;
  document.querySelector('#carousel a').href = slides[current];
}, 3000);
</script>

Auto-advancing carousel that triggers navigation — Correct

<!-- The carousel no longer auto-advances.
     Navigation between slides and to destination pages is entirely user-controlled.
     Pause and next/previous controls satisfy both 2.2.2 and 3.2.5. -->
<div id='carousel' aria-roledescription='carousel' aria-label='Featured promotions'>
  <div role='group' aria-roledescription='slide' aria-label='1 of 3'>
    <a href='/promo/summer'><img src='slide1.jpg' alt='Summer Sale — Shop now'></a>
  </div>
</div>
<div>
  <button type='button' aria-label='Previous slide' onclick='prevSlide()'>‹</button>
  <button type='button' aria-label='Next slide' onclick='nextSlide()'>›</button>
</div>

Common Mistakes

• Using onchange on <select> elements to immediately trigger window.location.href navigation without providing a separate submit button, forcing keyboard users into an immediate page change before they can confirm their selection.
• Implementing <meta http-equiv='refresh' content='30; url=...'> for session timeout handling without giving users a mechanism to extend their session or disable the automatic redirect before it fires.
• Using setTimeout or setInterval to call location.replace() or history.pushState() for "convenience" features like auto-saving with URL updates, which unexpectedly moves users to new browser history states.
• Opening new browser windows or tabs using window.open() triggered by a timer or an automated process rather than by a user gesture such as a click or keypress, which many browsers may block as a popup and which always constitutes an unsolicited context change.
• Auto-submitting a search or filter form using form.submit() inside a debounce function triggered by oninput on a text field — even with a delay — without providing a visible submit button as an alternative control mechanism.
• Providing a "turn off auto-advance" control that appears only after the first automatic navigation has already occurred, rather than before. The opt-out mechanism must be available to users before the first context change happens.
• Confusing content updates with context changes: live regions that update text in place (e.g., a stock ticker) are not context changes and are acceptable, but automatically replacing the entire visible page or navigating to a new URL is a context change and falls under this criterion.
• Assuming that providing a warning dialog before automatic navigation satisfies the criterion when the dialog itself is triggered automatically and traps keyboard focus. The user must be able to disable the behavior, not merely be warned about it.
• Using onblur or onfocusout event handlers to trigger form validation and auto-redirect to an error page or a different step in a multi-step form, without the user explicitly requesting to proceed.
• Deploying single-page application (SPA) routing that updates history.pushState based on scroll depth or time spent on a section — a pattern sometimes used for analytics — which constitutes an uninitiated context change and can confuse screen reader users whose virtual buffer is tied to the URL state.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes mandatory web accessibility requirements aligned with WCAG 2.2 for a broad range of entities operating in Turkey. The circular covers public institutions and agencies, e-commerce platforms, banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE).

The circular mandates compliance at WCAG 2.2 Level AA as the baseline standard for covered entities. WCAG 3.2.5 Change on Request is a Level AAA criterion and is therefore not directly required under the circular's minimum legal threshold. However, this does not mean it should be dismissed as irrelevant in the Turkish context.

Several categories of covered entities have strong practical reasons to pursue AAA conformance with 3.2.5. E-commerce platforms and travel agencies with large user bases often implement dynamic filtering, auto-suggest navigation, and promotional carousels — precisely the patterns most likely to violate this criterion. Banks and financial services providers, which handle sensitive transactions where unexpected navigation can cause errors or security concerns, benefit substantially from ensuring that all context changes are explicitly user-controlled. Healthcare portals, where users may be in vulnerable states and need predictable, calm interfaces, represent another category where exceeding the AA baseline with AAA criteria like 3.2.5 demonstrates both ethical commitment and practical user safety.

Public institutions subject to audit and reporting requirements under the circular should document their conformance level. While Level AAA is not legally mandated, achieving it — and documenting it — provides a defensible record of best-in-class accessibility commitment. For entities that serve users with disabilities as a primary or significant audience, such as the social security authority (SGK) or disability support services, pursuing Level AAA conformance is especially aligned with the spirit of the regulation.

Organizations that voluntarily meet WCAG 3.2.5 also position themselves favorably in the context of European Union accessibility alignment, as Turkey's digital trade relationships with EU member states increasingly involve accessibility as a procurement and partnership criterion. The European Accessibility Act (EAA), which took effect in June 2025, applies to products and services offered in EU markets — including those provided by Turkish companies to European users — and strongly encourages user-controlled interaction patterns consistent with 3.2.5.

In practical terms, Turkish development teams implementing Accsible's overlay SDK should ensure that any dynamically injected widgets, preference panels, or assistive controls do not themselves introduce uninitiated context changes. The SDK's toolbar and settings panel must open and close only in response to explicit user actions, and any navigation or content update triggered through the overlay must be user-initiated. This ensures that the accessibility solution itself does not create the very barriers it is designed to remove.