Do not auto-replace content users cannot stop
F61 is a documented failure, and its subject is more specific than auto-updating in general. What fails is a complete change of the main content, through an automatic update, with no way for the user to disable it from within the content. There is no time threshold. The five-second figure people carry across from the pause rule does not apply here. Any automatic replacement of the main content the user cannot switch off is the failure, whether it happens every thirty seconds or every ten minutes. What is asked for is smaller than a pause control. An option to disable the behavior is enough, so a checkbox that turns auto-update off satisfies it, and a manual refresh button with auto-update off by default is the stronger version of the same answer.
How we find it in an audit
Two procedures are published and source inspection is the preferred one, which reverses the order most people work in. Where the code is reachable we read it, looking for whatever triggers the replacement and for any mechanism to disable it. Where it is not, because the content comes from a third party or a content management system, we watch the network and the DOM and time the intervals. Then the question that decides it. Can the user turn this off from inside the content, and how would they ever find out.
How affected users experience it
A screen reader user is part way down a news page when the article they are reading is replaced by a different one. Their reading position is gone, the content around it is gone, and nothing announced that anything happened, so the first sign is a sentence that does not follow. A magnifier user is looking at a region of a page that no longer exists. Somebody with a cognitive disability loses the thread and starts the page again, and will lose it again on the next update, which is coming.
Passes vs. fails
Passes
<button onclick="loadLatest()">Check for new stories</button>
<label><input type="checkbox" id="auto"> Auto-update every 5 minutes</label>
<!-- Off by default, and switchable off from inside the content. -->Fails
setInterval(function () {
fetch("/api/latest").then(function (r) { return r.text(); }).then(function (html) { main.innerHTML = html; });
}, 30000);How this gets tested
The W3C publishes test rules that define what a checker looks for here.
- Meta element has no refresh delayA tool can check this
- Meta element has no refresh delay (no exception)A tool can check this
The other techniques filed under this rule
16 guides on this site are filed under 3.2.5 Change on Request. W3C documents this one as a failure of that rule, so it describes a way the rule gets broken rather than a way to pass it.
- G76sufficientUpdate content only when the user asks
- G110sufficientMake client-side redirects instant, not timed
- H76sufficientMake meta refresh redirects instant, never timed
- H83sufficientWarn users when links open new windows
- SCR19sufficientNever change context when a select changes
- SCR24sufficientOpen new windows only when the user asks
This guide is our interpretation of W3C technique F61: Failure of Success Criterion 3.2.5 due to complete change of main content through an automatic update that the user cannot disable from within the content. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.