Change on Request

Why it matters

An unrequested change moves the ground under the reader. For a screen reader user, a page that refreshes puts the virtual cursor back at the top, which is where they were before they started reading. W3C also makes a point almost nobody expects. Some readers rely on automatic context changes, because a single-switch user depends on the system animating through the options for them. So the answer is not always to remove the change. Making it happen only when the reader's preferences allow it is a conforming route too.

Who this rule protects

Screen reader users, people with low vision, people with motor impairments and people with cognitive limitations are the four groups W3C names.

How to check it yourself

1. 1Sit on each key page and wait without touching anything. Note whatever navigates, opens or replaces itself.
2. 2Check your redirects. Server-side and instant ones pass. A timed one fails.
3. 3Tab out of a form field without changing anything, and check that nothing submits, which is one of the documented failures here.
4. 4Leave tabs, accordions and dynamic menus alone. A change of content is not automatically a change of context.

Failures we see most often

• A meta refresh with a delay sends the reader to another page while they are still reading this one.
• A form submits when focus leaves a field, so somebody tabbing through loses the rest of it.
• Search results rewrite themselves under the reader as they type, with no way to switch that off.
• A new window opens on page load, or opens because the reader typed in a field.

Who this one is for

Read from this rule's own note above, so the grouping and the note cannot disagree.

• Blind and screen reader userspeople who cannot see the screen
• Low visionpeople who can see the screen but not easily
• Motor and keyboard-onlypeople who cannot use a mouse, or cannot use one precisely
• Cognitive and learningpeople for whom the difficulty is understanding, remembering, or staying with it

How this one is tested

We list 2 ACT rules against 3.2.5. Each one defines exactly what a checker looks at, which is how automated tools decide what to flag. Each one also checks a slice, so passing every rule here is not the same as meeting the criterion, and a rule can be proposed rather than approved or need a person to finish it. The note beside each says which.

• Meta element has no refresh delayA tool can check this
• Meta element has no refresh delay (no exception)A tool can check this

How to fix it

• Do redirects on the server. That is the first sufficient technique W3C names, and its stated benefit is that readers with cognitive limitations are not confused by them.
• Replace a timed client-side redirect with an instant one, or with a link the reader chooses.
• Offer an update-on-request control instead of refreshing content automatically.
• For a link that opens a new window, pair the target attribute with a plain statement in the link text. The words alone are advisory and do not satisfy the rule. Better still, do not open one, and let the reader decide.

Passes vs. fails