Interruptions
Anything that interrupts the reader has to be postponable or suppressible, unless it involves an emergency. Postponing counts. W3C's own worked example is a preferences page deferring all updates and alerts to the end of the session, so a permanent off switch is more than the rule asks for. Emergency is a defined word here, and it covers more than you would guess.
Why it matters
An interruption resets attention. For somebody with a cognitive disability that can mean losing the task entirely and having to work out where they were. W3C puts the screen reader case well. Content updating while somebody reads means they start in one topic and finish in another. That is also why the emergency carve-out is wider than it sounds. A warning about danger to health, safety or property counts, and W3C names data loss and loss of connection inside that. So the message telling somebody their session is about to expire and their work is about to vanish does not have to be suppressible.
Who this rule protects
People with attention differences feel this most, along with screen reader users and people with low vision whose reading gets cut across by an update they never asked for.
How to check it yourself
- Sit on a page for two minutes without touching anything and count what interrupts you.
- Check whether the reader can defer those updates rather than only kill them, since postponing to the end of the session is what W3C's own example does.
- Check whether any auto-refreshing content can be paused, or asked for on demand instead.
- Search the markup for a meta refresh, which is the one thing here an automated test can find.
Failures we see most often
- A feed re-announces itself constantly through a live region, so a screen reader user starts in one topic and ends in another.
- A page reloads itself on a meta refresh, which fails this rule and two others at the same time.
- Non-emergency alerts arrive with no way to defer them until the reader has finished.
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
- 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 2.2.4. 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
- Let people postpone all non-emergency updates for the session, which satisfies the criterion without building a permanent setting.
- Offer an update-on-request control instead of refreshing content underneath the reader.
- Make chat opt-in rather than something that opens itself.
- Leave genuine emergency messages alone. A warning about losing data is one, and it needs no off switch.
Step-by-step fix guides (5)
Passes vs. fails
Passes
The same page shows a button saying new stories are available, and only updates when the reader asks it to.
Fails
A news page reloads itself every 30 seconds on a meta refresh, mid-article.
In audits and lawsuits
This is Level AAA, and it is worth knowing how narrowly W3C frames it. The stated intent is about turning off updates from the author or the server. All three sufficient techniques are about content updating. Both documented failures are about meta refresh. Reading the criterion more broadly, so that it reaches chat widgets and newsletter modals, is defensible from the plain word interruption and it is how most of the field discusses it. It is not what the source material says, so we say both.