WCAG 2.2.1 Timing Adjustable

What it asks

Time limits are everywhere: a session that signs you out after fifteen minutes, a checkout that holds your tickets for ten, a form that expires, a page that reloads itself, a quiz with a clock. People read, type and move at very different speeds, and a limit set for a typical visitor can be impossible for someone who reads slowly, types with one hand or is working through a screen reader.

For each time limit the content sets, at least one of these must be true. Turn off: the person can switch the limit off before they meet it. Adjust: the person can change it before they meet it, over a range of at least ten times the default. Extend: the person is warned before time runs out, is given at least 20 seconds to extend it with a simple action such as pressing a key, and can extend it at least ten times.

Three kinds of limit are exempt. A real-time event, such as an auction, where the limit is part of the thing itself. A limit that is essential, where extending it would make the activity invalid, such as a timed test. And any limit longer than 20 hours.

The commonest case is the session timeout. A warning dialog that appears two minutes before expiry, with a "Stay signed in" button, meets the extend option. A session that expires silently, with the person’s half-finished form lost, does not.

Its official name is success criterion 2.2.1 Timing Adjustable, at Level A. It was added in WCAG 2.2, under guideline 2.2 Enough Time and the principle Operable. The W3C’s normative text says, in part:

“For each time limit that is set by the content, at least one of the following is true:”

From WCAG 2.2, W3C. Full explanation: Understanding 2.2.1 Timing Adjustable.

Who it helps

People who read slowly, including people with dyslexia and people reading in a second language. People with motor disabilities who type slowly or use switch access. Screen reader users, for whom a long form takes longer to work through than it does to look at.

People with cognitive disabilities, who may need more time to understand a question and decide an answer, and anyone who is interrupted partway through.

What passes and what fails

These pass

• A session that warns the person two minutes before it ends and offers a "Keep me signed in" button, which can be used again and again.
• A ticket basket with a countdown and an "Extend my time" button, available at least ten times.
• A sign-in page with a session limit of 24 hours, which is over the 20 hour exception.
• A carousel that advances by itself and has a pause button, which turns its timing off.
• An online auction whose closing time cannot be extended, because it is a real-time event.

These fail

• A session that expires silently, so the person returns from a break to find the form reset and their work gone.
• A checkout countdown with no way to extend it.
• A carousel that advances every few seconds with no pause, stop or hide control.
• A meta refresh that reloads or redirects the page after a delay, with no way to stop it.
• A warning that appears ten seconds before sign-out, with no time to react.

A short delay used only to redirect, such as a page that says "Taking you to the new address" and moves on after a few seconds, still counts as a time limit and fails unless the person can stop it. An immediate redirect, with no delay, is a different matter and is covered by 3.2.5 Change on Request at Level AAA.

How to test it by hand

1. List every time limit you can find: session expiry, basket holds, countdowns, auto-advancing carousels and steps, pages that reload or redirect themselves, and timed quizzes.
2. Check the page code for a meta refresh with a delay.
3. For a session limit, sign in, leave the page idle, and watch what happens as expiry approaches. Note whether a warning appears, how long before expiry, what action extends it, and how many times it can be extended.
4. For each other limit, look for a way to turn it off or set it longer before it starts, or to extend it when warned.
5. For anything with none of those, check whether it is a real-time event, essential, or longer than 20 hours.

What automated testing can decide

What a machine can decide

A timed meta refresh is in the page’s markup and can be found and measured exactly: it fails if the delay is more than zero and 20 hours or less. Automated testing can also notice content that reloads, redirects or advances by itself, and whether a pause or extend control is present beside it.

What it cannot

The session timeout, the limit that matters most, can only be observed inside a signed-in session, and only by waiting for it. Whether a limit is essential or belongs to a real-time event is a judgement about the activity, not a measurement of the page. Whether a control labelled "Pause" really stops the clock needs trying.

How Dreven handles it

Dreven finds the content on your pages that reloads, redirects or moves on by itself and shows you each instance, with the page and any pause or extend control found beside it. A reviewer decides each result.

Session limits can only be seen inside a signed-in session. Where an audit does not have one, the report says they were not observed, as a gap in coverage, never as a pass.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 2.2.2 Pause, Stop, Hide (Level A). Moving and updating content needs a pause, stop or hide control.
• 3.3.7 Redundant Entry (Level A). If a session does expire, people should not have to type everything again.
• 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA). A purchase or application cut short by a time limit needs a way to check and recover.
• 1.4.2 Audio Control (Level A). Audio that starts by itself must be stoppable, another rule about control over time.

Questions people ask

All WCAG 2.2 criteria, in plain words