CAPTCHAs, Logins and Timeouts: The Accessibility Traps on Public Service Portals

A resident wants to renew a permit, pay a utility bill or check a benefits claim. The page is accessible up to the moment it asks them to prove they are human, sign in, or finish before a countdown ends.

These gatekeeping steps are where otherwise conforming sites quietly fail. A user who cannot get through them cannot use the service at all, and, as the process rule in WCAG makes clear, a multi-step process conforms only if every step does.

What does WCAG say about CAPTCHAs?

WCAG 1.1.1 (Non-text Content) has a specific provision: where a non-text item is used to confirm that content is being accessed by a person rather than a computer, text alternatives must at least identify and describe the purpose of the item, and alternative forms of the test must be provided that use different modalities, so that different disabilities are accommodated.

In plain terms: an image puzzle with no alternative locks out blind users, and an audio puzzle with no alternative locks out deaf users and many others. Puzzles that depend on perception, memory or fine motor control exclude some users no matter how they are presented.

The practical options, from best to worst:

1. Avoid the CAPTCHA. Rate limiting, server-side checks and invisible risk signals can often do the job without asking the user to solve anything. Check how a given product works and whether it falls back to a puzzle.
2. Offer a genuine alternative such as an emailed or texted code, or a plain question answered in text, in addition to the visual or audio test.
3. Provide human help, with a phone number or contact route that is easy to find and actually staffed.

Whichever you choose, test it with a keyboard and a screen reader. Many CAPTCHA widgets are embedded from another company, which makes this an instance of the third-party content problem: the obligation stays with the entity that presents it.

What about login and authentication?

The current WCAG 2.2 standard added 3.3.8 Accessible Authentication (Minimum), which says a cognitive function test, such as remembering a password or transcribing characters, must not be the only way to authenticate unless an alternative or a mechanism to assist is available. WCAG 2.1 does not contain this criterion, so it is not a formal requirement where WCAG 2.1 is the named standard. What changed in WCAG 2.2 covers the differences. It is still good practice and a sensible thing to build toward.

You can follow it without knowing the detail:

• Allow password managers and paste. Do not block pasting into password fields or break autofill. Pairing the field with a correct autocomplete attribute also supports WCAG 1.3.5 (Identify Input Purpose), which is in WCAG 2.1.
• Offer an alternative to transcribing a code, such as a link or a code that can be pasted or filled in automatically.
• Do not make users solve a puzzle to prove who they are.

How do session timeouts cause failures?

WCAG 2.2.1 (Timing Adjustable) requires that, where there is a time limit, users can turn it off, adjust it, or extend it, with limited exceptions such as real-time events or limits that are essential. The usual pattern that works:

• Warn before the session ends, with a clear message that is announced to assistive technology.
• Allow at least 20 seconds to respond to the warning, and let the user extend with a simple action, such as pressing a key, at least ten times.
• Preserve what the user entered where possible, so a timeout does not wipe a long application.

A timeout that appears only as a visual pop-up, or that moves keyboard focus unexpectedly, can be worse than no warning.

Security teams sometimes insist on short timeouts. The exceptions in WCAG are narrow; if your policy depends on one, document why it is essential.

How should errors and help work?

Forms behind a login are forms like any other. WCAG 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion) require that errors are described in text and, where known, that suggestions for fixing them are provided. A message that says only “Invalid” in red text fails both, and fails 1.4.1 if colour is the only signal. Accessible government forms goes through labels, errors and grouping in detail.

Account recovery deserves special attention. “Forgot password” and identity verification flows are often built last and tested least, yet they are what a locked-out resident depends on.

Where does language make this harder?

Gatekeeping steps are often the least translated part of a portal.

• The CAPTCHA, the timeout warning and the error messages are frequently supplied by a third party and appear only in English even when the rest of the page is translated.
• Security questions and verification text may be translated badly, or not at all.
• Screen readers need the right language set on each element so translated text is pronounced properly (WCAG 3.1.1 and 3.1.2). Translated documents that fail WCAG 3.1.2 explains how that goes wrong.
• Machine-translated interface text can change the meaning of an instruction. Screen readers and machine translation describes why.

For public services, this is also a language-access question. Title VI and the ADA in one procurement explains how the two obligations meet.

A quick test you can run today

1. Complete a full sign-in and one transaction using only a keyboard.
2. Do it again with a screen reader running.
3. Wait for the session to time out and see what you are told and what you lose.
4. Make a deliberate error in each form and read the message out loud.
5. Repeat the test in each language the portal offers.
6. Write down what happened, with the date and device. A record like this is what a reviewer wants to see.

Where Taika fits

We review the words and structure of these steps: error messages, instructions, timeout warnings and recovery flows, and we translate and verify them in the languages your residents use. We do not replace your identity or security tooling, and will say so if the fix you need is engineering. We meet and exceed ISO 17100, 9001 and 27001 standards.

Reviewing a portal? Send us the sign-in and payment steps as screenshots or a link, the languages it offers, and which CAPTCHA or identity product it uses, then request a quote. Our ADA website accessibility page explains how we scope Title II website work.