Timing Adjustable

Why it matters

Time limits get built around an average user, and accessibility is the whole business of everybody who is not that user. A screen reader user hears a form field by field instead of taking it in at a glance. A person with dyslexia decodes the same text more slowly. Someone who is deaf and signs may be reading a second language, or waiting on an interpreter to relay it. A tremor makes every field a small negotiation. The numbers in the rule come from that reasoning rather than from thin air. Ten times the default came from the observation that a switch user given 15 seconds needs about 150, and 20 seconds is what it takes for almost anyone to hit any key at all. When the timeout lands anyway, it logs that person out, discards the work, and teaches them not to come back.

Who this rule protects

This affects screen-reader users hearing a form one field at a time, slow typists, people with cognitive or motor disabilities, deaf users for whom the page text is a second language or who are working through a sign language interpreter, and anyone for whom a form takes longer than it did in the demo.

How to check it yourself

1. 1Search the markup for a meta refresh with a delay on it, which is the part a tool can settle and the part most audits skip. Then ask for the server-side redirects that fire after a period of inactivity, because those are documented failures too and no scanner can see them.
2. 2Start a checkout or a long form, then wait. A warning should arrive with at least 20 seconds left, carry a one-action way to extend, and be reachable by keyboard and announced to a screen reader.
3. 3Count how many times the extension works. The rule asks for at least ten, so a dialog that gives up after the second extension fails.
4. 4Look past session timeouts. Anything that changes on its own clock is a time limit, including a dashboard that refreshes itself, a countdown banner, and content that advances faster than somebody can read it.
5. 5For a message that disappears on a timer, check whether the same information is reachable another way. A new-mail toast that vanishes is fine while the inbox still shows the mail. It becomes a time limit when nothing else carries the message.

Failures we see most often

• A session that dies at 15 minutes with no warning, taking the shopping cart with it.
• A 'you are still there' dialog that closes itself after 10 seconds, which stacks a second and crueller time limit on top of the first.
• An extend option that works twice and then stops, where the rule asks for at least ten.
• A page carrying a meta refresh with a delay on it, which reloads under the reader and drops them back at the top.
• A server-side redirect that fires after a period of inactivity and moves the user somewhere else mid-task.

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
• Deaf and hard of hearingpeople who cannot hear the audio
• 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 2.2.1. 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

• Ask first whether the limit needs to exist. Turning it off is the answer W3C ranks above the others, and it is usually cheaper than building a warning system.
• If it has to exist, make the length a setting the user chooses before they ever meet it, over a range reaching at least ten times the default.
• If you land on warn-and-extend, put a checkbox on the first page of the form asking whether the user wants a longer session, so nobody has to react under a clock. Warn at least 20 seconds out, make extending one keystroke, and allow at least ten extensions.
• Move everything you can out of the timed window. A ticketing site that collects the name, the address and the payment method before the seat hold starts has shrunk the timed part of the job down to the part that genuinely has to be timed.
• Where the limit is a timed exam, a third party can hold the clock instead. That is how an invigilator grants double time without invalidating the test.
• Preserving what the user typed across re-authentication is 2.2.5 at AAA, and it is the thing users notice most. Take advice before you build it. W3C's own note on the related timeout rule says privacy regulations may require explicit consent before user data is preserved, that consent often cannot be sought where the user is a minor, and that privacy professionals and legal counsel should be consulted first. Payment card and health data rules are the two it names.

Passes vs. fails