--- title: "Change on Request" url: "https://barrierefreihochzwei.de/en/wcag/3-2-5-change-on-request" language: "en" description: "WCAG 3.2.5 requires changes of context to happen only on request or to be switchable off – learn how to tame new windows, redirects and auto-refresh." published: "2025-01-01T08:00:00+01:00" updated: "2026-10-15T09:42:00+02:00" --- # Change on Request When websites only act on your command. - **Erfolgskriterium:** 3.2.5 - **Prinzip:** Understandable - **Konformitätsstufe:** Level AAA - **Erklärung beim W3C:** [www.w3.org/WAI/WCAG22/Understanding/chan...](https://www.w3.org/WAI/WCAG22/Understanding/change-on-request.html) Success criterion 3.2.5 # 3.2.5 Change on Request Level AAAUnderstandable When websites only act on your command. ## 1. What is the goal of this criterion? You’ve probably been there: you click a link and a new window suddenly pops up – without warning. Or you’re reading an article and the page reloads itself even though you didn’t ask it to. Surprises like these are frustrating – especially for people with disabilities. The goal of WCAG Success Criterion 3.2.5 is clear: you should be in full control of major changes on a website. Changes of context – such as new windows, automatic redirects or a page reload – may only happen if you trigger them yourself or if you can turn them off. ## 2. What exactly does it require? Specifically, it’s about changes of context – switching the page or window, moving focus, or content changes that alter the meaning of the page: **Changes of context only happen on request:** - New windows or tabs only open when you deliberately activate a link or button – ideally knowing that a new window is coming - There are no automatic, timed redirects - Forms are only submitted through a deliberate action, such as clicking the submit button - The page doesn’t reload on its own **Alternative:** there’s a mechanism that lets you turn off such automatic changes. **Important distinction:** unlike [On Input](https://barrierefreihochzwei.de/en/wcag/3-2-2-on-input), simply announcing the behaviour in advance isn’t enough here. On the other hand, content updates that aren’t a change of context are not affected, and neither are redirects that happen instantly on the server when a page is requested – after all, you asked for that page. An example: a news portal automatically reloads its home page at regular intervals to show new headlines. That’s fine if there’s a setting to turn off the automatic reload – or if new stories only appear after you click “Refresh”. ## 3. Why does it matter for accessibility? Imagine using a website with a screen reader when a new window suddenly opens – but you don’t notice right away. You try to go back, but the Back button doesn’t work as expected. Confusion is guaranteed. Controlled changes of context support accessibility because they: - **help blind and visually impaired people** keep their bearings when they can’t perceive visual changes, or only see part of the screen - **let people with motor impairments** navigate at their own pace - **protect people with cognitive disabilities** from confusion caused by unexpected changes - **help people with attention deficits** stay on task - **give everyone** a predictable experience And last but not least: people without disabilities also prefer websites that behave in a controlled, predictable way. ## 4. How to meet the criterion The good news: predictable websites are often easier to build and maintain, too. Here are some proven tips: **New windows and links:** - Open links in the same window by default - Only use `target="_blank"` deliberately and mark such links clearly, e.g. with “(opens in a new window)” - Avoid windows that open without a click – such as pop-ups on page load **Forms and inputs:** - Only submit forms after a deliberate click on the submit button - Avoid submitting automatically when someone leaves an input field - Only use `change` events for changes that don’t trigger a change of context **Automatic updates:** - Offer a “Refresh” button instead of automatic reloads - If automatic updates are necessary, add a switch to turn them off - Prefer targeted background updates that don’t reload the page or move focus **Redirects:** - Use server-side redirects (e.g. 301 or 302) instead of JavaScript redirects - Avoid `` with a time delay - If a client-side redirect is unavoidable: make it immediate, with no delay **Tools and techniques:** - Use progressive enhancement: the core functionality should work without automatic scripted actions - Announce updates that aren’t a change of context via live regions (see [Status Messages](https://barrierefreihochzwei.de/en/wcag/4-1-3-status-messages)) - Test pages with the keyboard and a screen reader for unexpected window, page or focus changes ## 5. Why this criterion matters for businesses With Success Criterion 3.2.5, too, accessibility isn’t an end in itself – it brings tangible benefits for your business. **1. Better experience, fewer drop-offs** Unexpected pop-ups and automatic redirects annoy everyone – not just people with disabilities. Predictable websites reduce frustration and abandonment. **2. Clean technology** Server-side redirects instead of timed script or meta redirects are good practice anyway: they’re faster, more robust and unambiguous for browsers and search engines alike. **3. Trust and credibility** Websites that behave unpredictably come across as unprofessional or even suspicious. Controlled, transparent flows build trust and strengthen your brand. On the legal side: 3.2.5 is a Level AAA criterion and isn’t explicitly required by the European Accessibility Act or its German implementation, the Barrierefreiheitsstärkungsgesetz (BFSG) – the harmonised standard EN 301 549 refers to WCAG 2.1 Level AA for web content. You do need to meet the related criteria [On Focus](https://barrierefreihochzwei.de/en/wcag/3-2-1-on-focus) and [On Input](https://barrierefreihochzwei.de/en/wcag/3-2-2-on-input), though; 3.2.5 takes them to their logical conclusion. This section is general information, not legal advice. ## 6. The success criterion in the W3C’s words > **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. In short: changes of context only happen when you ask for them – or there’s a way to switch them off. **Official explanation from the W3C** The W3C explains every success criterion in depth – with intent, examples and techniques. [Understanding 3.2.5](https://www.w3.org/WAI/WCAG22/Understanding/change-on-request.html) ## More criteria from “Understandable” [ 3.1.1 Level A ### Language of Page So screen readers find the right voice. ](https://barrierefreihochzwei.de/en/wcag/3-1-1-language-of-page) [ 3.1.2 Level AA ### Language of Parts When websites become multilingual. ](https://barrierefreihochzwei.de/en/wcag/3-1-2-language-of-parts) [ 3.1.3 Level AAA ### Unusual Words When jargon becomes a barrier. ](https://barrierefreihochzwei.de/en/wcag/3-1-3-unusual-words)