WCAG 3.2.5 Change on Request: Keeping Website Behaviour Predictable

What WCAG 3.2.5 “Change on Request” means

WCAG 3.2.5 Change on Request requires that a website only changes page context or major page behaviour when the user explicitly asks for it. That includes navigation to a new page, large layout shifts, or changing keyboard focus. The goal is predictable behaviour so people who use assistive technology can follow the flow.

Why predictable behaviour matters

Unexpected changes break orientation. Screen reader users lose their reading position. Keyboard users can be moved away from a control before they finish. Predictable behaviour reduces errors and frustration. It also reduces the need for repeated actions and makes recovery easier when something goes wrong.

How this connects to existing guidance

This idea aligns with existing WAI guidance such as the WCAG 2.x requirements that changes of context occur only on user request or after a clear confirmation. It also overlaps with rules about focus management and content updates. Treat Change on Request as a principle that sits alongside focus and live region rules.

When automatic changes are acceptable

Automatic updates are allowed in a few narrow situations. Use them only if the change is:

• small and non-disruptive, for example a micro-interaction that does not move focus or navigate away;
• clearly expected by the user, for example when a progress meter advances during a known upload;
• required for safety or to prevent data loss, and then provide a clear notice and an undo option when possible.

Common behaviours that fail Change on Request

• Submitting a form when a field loses focus without an explicit submit action.
• Opening a new page or modal on hover or on focus without a clear activation.
• Moving keyboard focus automatically when a nearby control is activated without informing the user.
• Replacing large sections of content while the user is reading without a request.

Acceptable alternatives and best practice patterns

Follow these patterns to keep behaviour predictable.

• Require an explicit activation. Use a clearly labelled button or link to apply changes such as sorting, filtering, or navigation.
• Keep in-page updates within a named region. Use a static container for updates and announce changes with aria-live when appropriate.
• Do not move keyboard focus unless the user requested a context change. If you must move focus, explain what happened and provide a way to return.
• Prefer progressive disclosure over immediate navigation. Let the user confirm large changes via a modal or a visible control.

Practical checklist to meet WCAG 3.2.5

Use this checklist during design, implementation and testing.

1. Identify flows that change page context: navigation, modals, major layout swaps.
2. For each flow, ensure a clear, labelled control exists to trigger the change.
3. Confirm automatic focus moves happen only after explicit activation. If focus moves, expose a visible reason and an easy way back.
4. Use aria-live regions for in-place updates instead of changing context or moving focus.
5. Test with keyboard only and with a screen reader to confirm the user stays oriented.
6. Provide undo or cancel where a change might cause data loss.

Testing steps you can run in 10 minutes

• Turn off the mouse. Navigate the page with Tab. Check whether controls activate unexpected navigation or large layout changes.
• Open a screen reader. Move through headings and interactive elements. Note any sudden page or focus changes that are not triggered by explicit actions.
• Try auto-complete and live search. Confirm results update without changing page context or stealing focus.

Common developer mistakes and how to fix them

Auto-submit on blur

Problem: A field auto-submits when it loses focus. That can send users away while they are still completing the form.

Fix: Require a submit button. If you keep auto-save, make it clearly visible and non-disruptive. Offer an undo for the saved change.

Moving focus programmatically without notice

Problem: Scripts call focus() after an update and the user loses context.

Fix: Only call focus() after a user action that implies a context change. When you do focus(), put an accessible message in the target so screen reader users understand why focus moved.

Using aria-live as a shortcut to move attention

Problem: Developers rely on aria-live to force screen reader users to inspect new content instead of providing a requested activation.

Fix: Use aria-live for small updates like status messages. For major content changes require a user action and do not rely on live regions alone.

Accessibility technical notes

• Use WAI-ARIA roles and properties to label update regions. For example, aria-live=“polite” suits unobtrusive status updates; aria-live=“assertive” should be used rarely.
• When you expose controls that open new context, include clear accessible names and visible labels. Screen reader users must know what will happen before activation.
• Follow focus order that matches visual order. Keep tabindex usage to a minimum to avoid surprises.

Real-world examples

Good example: A filter panel that changes results when a user clicks Apply. The page does not navigate away and focus stays on the button. The results container is updated and a small aria-live message announces the number of results.

Poor example: A hover menu that navigates to a new page when a focusable item receives keyboard focus. That surprises keyboard users and can be triggered without intent.

When to document behaviour

Document any non-standard behaviour in your accessibility statement and in component documentation. Explain which controls trigger navigation, when focus will move, and how users can undo changes. Clear documentation helps assistive technology users and testers.

Summary checklist

• Require explicit activation for navigation and major changes.
• Do not move focus unless requested and then provide context.
• Use aria-live for small updates only.
• Test with keyboard and screen reader.
• Document any exceptions and provide undo where possible.

Following these steps will keep behaviour predictable and make your site easier to use for people who rely on assistive technology. Keep changes on request and you reduce confusion while improving overall usability.