Accessible authentication and CAPTCHA: what WCAG 3.3.8 requires

What success criterion 3.3.8 Accessible Authentication (Minimum) says

The W3C states the goal plainly: make logins possible with less mental effort. Some people with cognitive disabilities cannot solve puzzles, memorize a username and password, or retype one-time passcodes. The W3C explicitly treats remembering a site-specific password as a cognitive function test, and notes that remembering random strings of characters or a pattern gesture to perform on a touchscreen will exclude some people.

The criterion targets authentication of existing users. It does not cover creating a username or initiating an account, although the same techniques (allowing paste, not relying on transcription) also reduce the burden of sign-up. Being able to recover or change the email and password is, however, an important part of authentication: if users authenticate with alternative information to recover their account, there must be a method that is not a cognitive function test.

• Alternative: another authentication method that does not rely on a cognitive function test.
• Mechanism: something assists the user in completing the test, for example password manager support or copy and paste.
• Object recognition: the test is to recognize objects (images, video or audio).
• Personal content: the test is to identify non-text content the user provided to the website.

Accessible authentication and CAPTCHA: what is not allowed

Every step counts. With multi-factor authentication, all steps must comply: there needs to be a path through authentication that does not rely on cognitive function tests. The criterion also applies to CAPTCHAs and tests that only appear in certain situations, such as when an ad blocker is present or after repeated incorrect password entry.

The W3C lists failure F109: failure of success criteria 3.3.8 and 3.3.9 due to preventing password or code re-entry in the same format. The page also describes concrete cases that force transcription or rely on a cognitive test, and that are a problem when no other authentication method without a cognitive test is available:

• A password field that prevents pasting and tells the user to type the password manually.
• A script that stops the browser or a password manager from filling in the fields automatically.
• A request such as "Enter the 1st, 3rd and 5th character of your password", which forces transcription.
• A 6-digit one-time code split across 6 separate inputs, where pasting the code only fills the first digit.
• A verification code that must be transcribed manually, with no paste or autofill.
• A distorted-text CAPTCHA: its audio alternative cannot count as the Alternative exception if the user has to transcribe it.
• A math CAPTCHA or a visual puzzle, such as rotating a 3D model of a walrus to match a given direction.
• Text-based personal content: it does not qualify for the personal content exception because it relies on recall rather than recognition, and on transcription rather than selecting an item.

What is allowed: password managers, copy and paste, test-free methods

Username (or email) and password remain acceptable, provided the browser and third-party password managers can fill in the fields. According to the W3C, if the form meets 1.3.5 Input Purpose and the controls have an appropriate accessible name under 4.1.2 Name, Role, Value, user agents and password managers should be able to recognize and fill them reliably. Copy and paste also avoids transcription: users copy credentials from a standalone password manager and paste them into the form.

Sufficient techniques listed by the W3C include email link authentication (G218) and properly marked up email and password inputs (H100). The examples on the page also include:

• WebAuthn, letting users authenticate with their device (for example face scan, fingerprint or PIN, whichever they set up).
• Login through a third-party provider using OAuth.
• Two-factor authentication with several options, including a USB-based method where the user simply presses a button to enter a time-based token.
• A QR code scanned by an app on the user's device.
• A notification sent to the user's device and confirmed with that device's own authentication mechanism.

Object recognition CAPTCHAs and personal content

A CAPTCHA asking users to select every image containing a car falls under the object recognition exception at Level AA. An object here means a material thing that can be seen and touched, including vehicles and animals. Once the test goes beyond recognition, for example multiplying the number of cats by the number of dogs, the exception no longer applies. And a test based on something the website set, such as remembering or transcribing a word, is a cognitive function test.

Personal content works like this: during account creation the user uploads a picture, then picks it out from several options when logging in. The W3C asks for adequate security here, since an illegitimate user might guess the right picture. More importantly, it notes that both exceptions do not fully support the cognitive accessibility community and should be avoided if possible: they are not excepted under 3.3.9 Accessible Authentication (Enhanced) at Level AAA.

The W3C also points out that an option to show the password can improve the chance of success for some people, when typing is still necessary, for example when creating a password to be saved by a password manager.

Verification codes and two-factor authentication

A service that requires manual transcription of a verification code is not compliant. At minimum, users must be able to paste the code (from a password manager, a text message app or a software-based security key) and the browser must be allowed to fill the field automatically.

When the code arrives on a secondary device, such as an SMS sent to a phone while logging in on a laptop, how the code gets transferred between devices is outside the scope of the criterion. Evaluators assume the code is available in the clipboard and only check that the code field accepts pasting. The W3C also states that two-factor systems that do not rely on codes are not cognitive function tests: hardware keys such as a YubiKey, apps that ask users to confirm it is really them logging in, and operating system methods such as Windows Hello, Touch ID and Face ID.

Why the note "Inaccessibility of CAPTCHA" considers CAPTCHA inaccessible

"Inaccessibility of CAPTCHA" is a Group Draft Note dated 16 December 2021, published by the Accessible Platform Architectures Working Group as an update to the Note published in 2019. It is not endorsed by W3C or its Members and is presented as work in progress. Its finding is blunt: the very nature of the interactive task excludes many people with disabilities, amounting to a denial of service.

Asking blind, visually impaired or dyslexic users to read distorted characters asks them to do the task they are least able to accomplish; the same goes for audio CAPTCHAs and deaf or hard of hearing users. Traditional CAPTCHAs also often assume English, and a design that expects multiple attempts as a matter of course is, the note argues, arguably inaccessible by design to people living with an anxiety disorder and to many people with other cognitive and learning disabilities. The note also cites Cloudflare data putting the average time to complete a CAPTCHA at 32 seconds.

The note adds that CAPTCHA is becoming less effective as security: image, logic and audio approaches can be largely cracked by algorithms. It cites a University of Maryland study reaching a 90% success rate against Google's audio reCAPTCHA.

CAPTCHA alternatives presented in the note

All else being equal, the note's authors prefer non-interactive approaches because they pose no accessibility challenges, while warning that they may expose users' personal data. The Understanding page for 3.3.8 also mentions rate-limited access, client geo-location and private client authentication: none is 100% effective, but they may reduce the likelihood of a CAPTCHA being displayed.

• Spam filtering (hot words, Bayesian filtering): well-tuned systems can match a visual CAPTCHA without adding cognitive burden.
• Proof of work: JavaScript computation on the client verified by the server, with no direct accessibility problem, though it may slow older hardware.
• Heuristics: spotting robots from requested data volume, pages visited, IP addresses or data entry methods.
• Honeypots: a field visible to robots but hidden from humans, easy to implement.
• Limited-use accounts: limiting how often new accounts can interact.
• Among interactive approaches, biometrics with a choice of multiple identifiers, or cryptographic attestation of personhood built on WebAuthn.
• Tokens such as Privacy Pass: they still begin with a CAPTCHA challenge but greatly reduce later interactive challenges.
• If an interactive CAPTCHA is still needed: show it as rarely as possible and offer several challenges that use different sensory and cognitive abilities.

How to check your login flow

Walk through every step, including two-factor authentication, account recovery and tests triggered only after errors. Paste a password and a code from a password manager: both must be accepted in full. Check that the password manager fills the fields and that they have an accessible name. If a CAPTCHA remains, make sure another login path without a cognitive test exists. For the rest of your pages, a free test and continuous monitoring with Conformly help you track your accessibility over time.

Frequently asked questions

Further reading on Conformly

• RGAA criterion 1.4 on CAPTCHA text alternatives
• RGAA criterion 1.5 on alternative CAPTCHA access
• Our overview of RGAA 5 and what changes

Sources

This article relies on the official sources listed at the end of the page.

• W3C — Comprendre 3.3.8
• W3C — Inaccessibility of CAPTCHA