3.2.5 Change on Request

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, 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 <meta http-equiv="refresh"> 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)
• 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 and 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.