Do not auto-redirect after a server-side timeout
F58 is a documented failure under the timing adjustable rule, and it is the only member of the meta refresh family filed under that rule alone. The server sends a Refresh header with a delay, and the page moves on its own after a period the user cannot turn off, extend or adjust. Two things about it are worth carrying. There is a second form with no URL in it, a plain Refresh header with a number, which reloads the same page on a timer and sits inside F58 rather than F41 because it comes from the server. And the header has never been part of any HTTP specification. It is non-standard, which is a reason to replace it with a 301 or a 302 quite apart from anything about accessibility. The same two exception checks come before a finding stands, real-time content and timing that is essential to the activity.
How we find it in an audit
Reading response headers is mechanical and we automate it across the whole site, which catches every instance rather than the ones somebody remembered. Then a reviewer applies the two exception checks, and looks at whether the user is given any way to turn off, extend or adjust the timing. Where a session timeout is driving the redirect, the terms are set. At least twenty seconds of warning, a simple action to extend, and at least ten extensions available.
How affected users experience it
Reading a page through a screen reader takes longer than reading it by eye, and a thirty-second server-side redirect was timed by somebody reading by eye. The page is replaced mid-sentence, with no announcement, and the reader arrives somewhere else with no idea what happened or how to get back. Part way through a form the loss is worse, because a redirect is a page load, and a page load takes the fields with it.
Passes vs. fails
Passes
<div role="alertdialog" aria-label="Session expiring">
<p>Your session ends in 2 minutes.</p>
<button onclick="extendSession()">Stay signed in</button>
</div>
<!-- 20 seconds of warning at minimum, a one-press extension, and at least ten of them. -->Fails
Refresh: 30; url=https://example.com/session-expired
<!-- Sent as an HTTP header. The page moves in 30 seconds, whatever the reader is doing. -->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
11 guides on this site are filed under 2.2.1 Timing Adjustable. 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.
- G4sufficientLet users pause moving content and resume it
- G133sufficientOffer longer session limits before forms begin
- G180sufficientLet users extend time limits tenfold
- G198sufficientLet users switch time limits off entirely
- SCR1sufficientLet users extend a script's time limit
- SCR16sufficientWarn users before a time limit runs out
This guide is our interpretation of W3C technique F58: Failure of Success Criterion 2.2.1 due to using server-side techniques to automatically redirect pages after a time-out. 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.