Skip to content

This translation has not been editorially reviewed yet. The German version is authoritative. Deutsche Fassung →

Accessibility

Why must time limits on websites be extendable?

Time limits on websites must be switchable off, adjustable, or extendable, because people read, type, and understand at different speeds. WCAG requires: a warning appears before expiry, and for at least 20 seconds, a simple action is enough to extend the deadline — up to ten times. Anyone working more slowly, with a screen reader or after a stroke, say, would otherwise lose every entry in the middle of a checkout.

Where time limits show up in everyday use

The best-known time limit is automatic logout: a customer portal ends the session after a period of inactivity, and every form field that was typed in is gone. Ticket shops also reserve seats for only a limited time, and some pages reload themselves automatically. For people working with a screen reader, entering every input with a mouth stick, or needing to read text several times, such deadlines are quickly too short. WCAG allows exceptions: real-time events like a live auction, cases where the limit is essential, and deadlines longer than 20 hours. Everything else needs a warning and an extension.

How the audit service checks time limits

Part of this is detected by the automated check: a page that reloads or redirects itself after a set time via a fixed instruction in the source code is machine-detectable and flows into the report as a violation. Whether a login time limit in your customer portal warns in time and can be extended, though, only becomes apparent over many real minutes — a human judges that. The audit report cleanly separates the two: every WCAG criterion appears individually as passed, violated, needs manual review, or not automatable. That way you know exactly what claim the measurement covers.

  • List every place with an expiring deadline: automatic logout, reserved shopping carts, self-reloading pages.
  • Have a warning appear before every expiry that can be confirmed with a single click or keypress.
  • Ask your agency to preserve entered form data when a session expires, instead of discarding it.
  • Remove automatic page reloads from the source code — they throw users out of their reading flow without warning.

FAQ

Which time limits require an extension under WCAG?

Basically any limit after which content disappears or entries expire: automatic logouts, expiring reservations, self-reloading pages. Users must be able to switch off the limit, adjust it, or extend it with a simple action — with a warning and at least 20 seconds to react. Real-time events like auctions, essential deadlines, and limits over 20 hours are exempt.

Why are short session logouts an accessibility problem?

People using a screen reader, with motor impairments, or with concentration difficulties need considerably longer for the same task: every field is read aloud, every entry set individually. If the session expires in the meantime, every entry is lost and the process starts over — often more than once. A timely warning with a simple extension solves the problem without giving up the security of logging out.

Does an automated check detect time limits on my website?

Partly. A fixed reload or redirect instruction in the source code is machine-detectable and counts as a violation. Session logouts and expiring reservations, on the other hand, only become apparent over many real minutes — a human judges those. Our audit report openly states which part was measured and which remains a manual check point.

Deutsche Fassung dieser Seite