WCAG 2.2.6 Timeouts: Understanding Accessibility Requirements for Expiring Sessions

Overview: WCAG 2.2.6 Timeouts

WCAG 2.2.6 Timeouts covers cases when an inactivity timeout will end a user session or cause loss of unsaved data. The goal is simple. Warn the user and provide a way to extend the session or save work unless the timeout is strictly required for security or legal reasons.

What the success criterion expects

At a high level, the criterion requires three things when a user faces an expiring session:

• A clear warning before the timeout that describes what will happen.
• An easy, accessible way for the user to extend the session, or to save their work before the timeout.
• Reasonable exceptions when the timeout is necessary for security, legal, or safety reasons.

Who this applies to

Any interactive page where inactivity can cause data loss or end an authenticated session. Examples include online banking, tax or benefits forms, medical record editors, and multi-step applications.

When a timeout may be allowed without extension

Some timeouts are unavoidable. Examples are forced logouts required by law or where extending a session would create an unreasonable security risk. Even then, provide ways to save data when practical. Do not rely on the exception to skip user-facing warnings if data can be preserved.

Design and UX requirements

Design the warning and controls so that all users can act before the session ends.

Warning timing and wording

• Show the warning well before automatic expiry so users can respond. For long forms a few minutes notice is typical; for short sessions a shorter notice may be fine.
• Use plain language. Example: “Your session will time out in 2 minutes. Choose Continue to stay signed in or Save to keep your work.”
• State the consequence: will you end the session, discard changes, or save data automatically?

Controls to extend or save

• Provide at least one control to extend the session, and one to save or export unsaved work when appropriate.
• Make these controls operable by keyboard and visible on small screens.

Keyboard and screen reader access

• Ensure the warning dialog can receive focus and that focus moves into the dialog when it appears.
• Implement an accessible dismiss or extend button reachable by Tab and Enter.
• Use an ARIA live region or role=“alert” to announce the timeout to screen readers if the user is not focused on the page.

Countdowns and visual indicators

• Show a clear countdown in minutes and seconds. Do not rely on color alone.
• Update the countdown at a readable pace, for example once per second or once per five seconds for long warnings.

Technical implementation checklist

Split work between client and server. The server owns session validity. The client provides the notice and the UI to request extension.

Front-end

• Track idle time and remaining session lifetime using the shorter of server token expiry and client timeout.
• Open an accessible modal when remaining time reaches your warning threshold. Move focus into it and return focus when it closes.
• Announce the warning via an ARIA live region so screen readers receive the message promptly.
• Offer explicit actions: Extend session, Save draft, or Log out now.
• Persist user choices when sensible, for example remember a user-checked “Stay signed in” preference if security policy allows.

Back-end

• Provide an endpoint to refresh or extend the session securely. Use short-lived tokens and rotate them.
• Support an autosave or draft API so the client can save partial work before the timeout.
• Return remaining session lifetime in API responses so the client can set an accurate warning timer.

Testing steps

1. Keyboard test: open the warning using only keyboard, operate Extend and Save, and confirm focus management.
2. Screen reader test: trigger the warning while a screen reader is running and confirm the announcement and action availability.
3. Low vision test: check contrast, large type scaling, and visible countdown.
4. Automated test: simulate token expiry and verify the server rejects requests after expiry and that the client shows the warning before rejection.
5. Real-world test: complete a long form, let it approach timeout, and confirm the save/export flow preserves data.

Common mistakes and how to avoid them

• Showing the warning too late. Start the warning early enough for a user to act.
• Using a non-focusable banner that screen reader users miss. Use a modal or an ARIA live region and manage focus.
• Relying on color or animation alone to convey urgency. Add text and a numeric countdown.
• No server endpoint to extend the session. The client UI must be backed by a secure refresh mechanism.

Real-world scenario: long application form

Problem: A user fills a 45-minute benefits form and the session times out after 20 minutes of inactivity. Data is lost.

Practical fix:

1. Autosave drafts every minute to a draft API.
2. Use the server-provided token expiry to schedule a warning five minutes before expiry.
3. Show an accessible dialog with the remaining time and actions: Save draft, Extend 30 minutes, or Log out.
4. If the user chooses Extend, call the refresh endpoint and resume the timer.

Checklist before launch

• Warning appears before expiry and is visible on all viewports.
• Dialog is keyboard operable and announced to screen readers.
• Server rejects expired tokens and supports a secure refresh action.
• Autosave or export option exists when data loss is possible.
• Business or legal timeouts are documented and justified.

Summary

WCAG 2.2.6 Timeouts asks teams to warn users about impending timeouts and to give them practical ways to save or extend a session. Implement both front-end and back-end measures, test with assistive tech, and avoid common mistakes like late warnings or non-focusable notices.