Signing in is the moment a website decides who gets in and who stays out. When that step demands a puzzle - transcribing distorted characters, recalling a complex password from memory or copying a code without error - it locks out precisely the people least able to cope. With WCAG 2.2, the W3C therefore introduced two new success criteria: SC 3.3.8 Accessible Authentication (Minimum, Level AA) and SC 3.3.9 (Enhanced, Level AAA). Both prohibit cognitive function tests during sign-in unless a low-barrier alternative exists (W3C WAI, 2023). The WebAIM Million Report 2025 shows how urgent this is: 94.8 percent (WebAIM Million, 2025) of all analyzed home pages had at least one automatically detectable WCAG failure. This guide explains what SC 3.3.8 actually requires and how to implement conformant login, registration and CAPTCHA flows.
What SC 3.3.8 and 3.3.9 Actually Require
At the heart of it is the concept of a cognitive function test. The W3C describes it as a task requiring users to remember, process or transcribe information - for example recalling a password or pattern from memory, deciphering distorted characters or solving a calculation or puzzle (W3C WAI, 2023). Such tasks are especially hard for people with memory limitations, dyslexia, dyscalculia or reduced processing speed. SC 3.3.8 at Level AA therefore requires that no step of the sign-in forces such a test, as long as none of the permitted exceptions applies.
The criterion names four ways to stay conformant (W3C WAI, 2023). First, an alternative: a second sign-in method that works without a cognitive test. Second, a mechanism that helps pass the test - such as unhindered use of a password manager or pasting a code from the clipboard. Third, a test that only requires object recognition, meaning naming everyday things rather than deciphering text. And fourth, a test in which users recognize content they provided themselves. Once one of these exceptions is met, the sign-in counts as accessible under the criterion.
Not Permitted and Permitted at a Glance
For legal classification, the conformance level is decisive. SC 3.3.8 sits at Level AA - the level the German Accessibility Strengthening Act (BFSG) has made mandatory for many digital services since June 2025 (BFSG, 2025). The harmonised European standard EN 301 549 still references WCAG 2.1 in its current version 3.2.1 and does not yet formally contain SC 3.3.8 (EN 301 549, 2021). With version 4.1.1, expected in 2026, the standard catches up to WCAG 2.2 - anchoring accessible authentication in the formal test benchmark too. Building to WCAG 2.2 today prepares you for that step; the article on EN 301 549 as the standard behind the BFSG explains the connections.
Do Not Block Password Managers: autocomplete and Pasting
The most effective and at the same time simplest contribution to SC 3.3.8 costs almost nothing: login fields must not hinder the use of password managers. The W3C explicitly names password managers as well as copy and paste as mechanisms that reduce the memory and typing burden (W3C WAI, 2023). Technically, the username field gets autocomplete="username", the password field autocomplete="current-password" and a registration form autocomplete="new-password". This lets browsers and password managers reliably recognize, fill and store credentials.
<label for="user">Username or email</label>
<input id="user" name="username" type="text"
autocomplete="username" />
<label for="pw">Password</label>
<input id="pw" name="password" type="password"
autocomplete="current-password" />
<!-- One-time code in ONE field so pasting stays possible -->
<label for="otp">One-time code</label>
<input id="otp" name="otp" inputmode="numeric"
autocomplete="one-time-code" />Just as important is what to avoid. A script that blocks pasting into the password field forces users into error-prone typing and violates the criterion unless an alternative exists (W3C WAI, 2023). Splitting a one-time code into six separate fields, into which a copied code cannot be pasted in one go, also creates an unnecessary transcription task. A single field with autocomplete="one-time-code", by contrast, allows pasting and, on mobile devices, even automatic entry from the SMS.
Do Not Block Pasting
Magic Links and Passkeys as a Strong Alternative
Where a second, cognitively lighter method is needed, two approaches have proven themselves. The email magic link sends a one-time sign-in link to the stored address; one click is enough, with nothing to remember and nothing to type. Passkeys based on the open web standards WebAuthn and FIDO2 replace the password with a cryptographic key held in the device and released via fingerprint, facial recognition or a device PIN. Both methods satisfy the alternative exception of the criterion because they work without a cognitive function test.
It is important to offer the alternative on equal footing and not hide it behind a CAPTCHA or an overlaying element. Just as a cookie banner must not cover the sign-in form - the guide to accessible cookie banners shows the conformant approach - the lighter method should not be hidden either. An accessible sign-in puts it visibly up front and keeps the classic password path available as an equal option. This preserves access even when one method is temporarily unavailable, for example because a user does not have their biometric device to hand.
Email Magic Link
A one-time sign-in link by email. No password to remember, no code to type - one click signs the user in.
Passkeys (WebAuthn)
A cryptographic key in the device, released by fingerprint or PIN. Meets the alternative exception of SC 3.3.8.
Password Managers
Correct autocomplete tokens let managers recognize and fill credentials - the helper mechanism named by the W3C.
Paste a One-Time Code
A single field with autocomplete=one-time-code allows pasting and automatic entry from the SMS.
Biometrics
Fingerprint or facial recognition replace the memory task entirely, without any characters being entered.
Federated Sign-In
Signing in via an existing account shifts the check instead of demanding a new cognitive test.
Low-Barrier CAPTCHA Alternatives
CAPTCHAs have been the most frequently cited barrier among screen reader users for years. In the WebAIM Screen Reader User Survey 10 (2024) with 1,539 participants, the distorted text CAPTCHA again ranks at the top of the most problematic items; people with disabilities cite it as problematic roughly twice as often (WebAIM Survey 10, 2024) as people without disabilities. The core problem is not protection against bots but the nature of the task: deciphering distorted characters is a visual and cognitive test that many users cannot pass.
| CAPTCHA type | Barrier | Low-barrier implementation |
|---|---|---|
| Distorted text | Visual and cognitive deciphering, unreadable to screen readers | Replace with object recognition or an invisible server-side check |
| Image grid (traffic lights, cars) | Requires fine motor control and fast image analysis | Object recognition with a clear task plus an equal audio alternative |
| Calculation or logic task | Cognitive function test with no exception | Not permitted - replace with a honeypot or rate limiting |
| No visible test | Creates no user task | Evaluate a honeypot field plus timing and behavior heuristics server-side |
The most pragmatic route is often to drop the visible test entirely. A honeypot field that stays invisible to people but is filled in by automated scripts catches a large share of simple bots without creating any user task at all. Combined with server-side heuristics - timing between page load and submission, rate limiting per address, checking for suspicious patterns - this creates protection that makes sign-in harder for no one. We use such invisible methods as standard in accessible web development.
Object Recognition, Server-Side Checks and an Audio Alternative
Where an interactive test is unavoidable, the W3C names object recognition as a permitted exception (W3C WAI, 2023). Instead of distorted characters, the test shows everyday objects and asks the user to select, say, all images with a dog or a traffic light. That is a perception task, not a memory test - and thus considerably more accessible for people with reading or arithmetic difficulties. What matters is that the task is clearly worded, the images are large enough and the selection is fully operable by keyboard.
A purely visual object test is not enough for blind users. It therefore needs an equal audio alternative that presents a spoken task, plus clean markup with labels and live regions so that screen readers announce both task and result. How these ARIA mechanisms interact is covered in depth in the article on ARIA roles, states and live regions. The actual check should also run server-side so that it cannot be bypassed in the browser.
- Replace visible text CAPTCHAs with an invisible honeypot and server-side heuristics
- If a test is needed: use object recognition of everyday items instead of distorted characters
- Provide an equal spoken audio alternative for every visual test
- Make the task, selection and result fully operable by keyboard
- Run the check server-side and announce results via a live region
- Allow password managers, pasting and autocomplete tokens throughout
Applying SC 3.3.8 to Registration, Login and Checkout
Accessible authentication is not only a legal question but a conversion lever. The Baymard Institute attributes 26 percent (Baymard Institute) of checkout abandonments to a forced account requirement and a further 22 percent (Baymard Institute) to a process that is too long or complicated. Every hurdle at registration and login - from the CAPTCHA to the password requirement - has a direct effect on revenue here. A guest checkout, a magic-link sign-in and a login that allows password managers lower abandonment and satisfy SC 3.3.8 at the same time. This is especially visible in the accessible checkout of an online shop.
Accessible Sign-In Pays Off Twice
A sign-in is only accessible once a person can complete it without a memory feat and without a puzzle - with a password manager, by magic link or with a passkey.
Whether a sign-in is actually conformant only becomes clear in a manual test. Automated tools detect many technical defects - the WebAIM Million Report 2025 counted an average of 51 errors (WebAIM Million, 2025) per home page - but whether a password manager works, a code can be pasted and an audio alternative functions can only be judged with keyboard and screen reader. That is exactly what we check in the WCAG 2.2 audit and in ongoing screen reader testing. Which further criteria WCAG 2.2 brings is set out in the overview of the new WCAG 2.2 success criteria. Teams that want to implement these patterns themselves are supported by our training on accessible development and the implementation of accessible authentication.