In short and in plain language
This article shows how to sign in without hurdles. Many sites ask for a puzzle. You have to type warped letters or remember a password.
The WCAG are rules for accessible websites. Under these rules, such a test at sign in is usually not allowed. The exception is when there is an easy way next to it.
A password manager should be able to fill in the field. Pasting must work too. A link by email or a passkey works without remembering anything.
A hidden field can block spam. Users do not have to do anything. If a test is needed, it should be easy. It should also work as audio.
This matters for anyone who offers a login. We build such sign in flows for you.
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.
Key takeaways
- WCAG 2.2 SC 3.3.8 (Level AA) bans cognitive function tests at sign-in: recalling passwords from memory, deciphering distorted characters, solving arithmetic or logic puzzles. The stricter SC 3.3.9 (Level AAA) drops object recognition as an exception too.
- Four routes satisfy the criterion (W3C WAI, 2023): an alternative method without a cognitive test, a helper mechanism such as a password manager or pasting, a test based purely on object recognition, or recognising content the user supplied themselves.
- Login fields need autocomplete=username, current-password and new-password on registration, with one-time codes in a single field using one-time-code. Blocking paste or splitting a code across six boxes creates a needless transcription task.
- Email magic links and passkeys built on WebAuthn and FIDO2 satisfy the alternative exception because nothing has to be memorised or typed. Offer them visibly alongside the password path rather than hiding them behind a CAPTCHA.
- Distorted-text CAPTCHAs again top the list of problematic elements in the WebAIM Screen Reader User Survey 10 (2024) and are named roughly twice as often by people with disabilities. A honeypot field plus server-side heuristics protects without a user task.
- Where a test is unavoidable, use object recognition of everyday items, an equivalent audio alternative, full keyboard operation and server-side verification. In checkout, 18 percent of surveyed US online shoppers cite forced account creation as a reason to abandon (Baymard Institute).
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 harmonised European standard EN 301 549 maps for web content. The German Accessibility Strengthening Act (BFSG) has applied since 28 June 2025 and ties the presumption of conformity to harmonised standards whose references are published in the Official Journal of the EU (Section 4 BFSG). EN 301 549 version V3.2.1 still references WCAG 2.1 and does not contain SC 3.3.8 (EN 301 549, 2021). Version V4.1.1, published in September 2026, is aligned with WCAG 2.2 and contains the criterion as clause 9.3.3.8 (EN 301 549 V4.1.1, 2026); it only gives rise to a presumption of conformity once its reference is published in the Official Journal. 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 - without anyone having to memorise a string of characters.
<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 can catch simple bots without creating a user task. Combined with server-side heuristics - timing between page load and submission, rate limiting per address, checking for suspicious patterns - this creates protection that needs no additional task from users. Such invisible methods are part of our accessible web development service.
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. In the Baymard Institute's latest survey of US online shoppers, 18 percent (Baymard Institute) name being required to create an account as a reason for abandoning checkout and 17 percent (Baymard Institute) a process that is too long or complicated. Every hurdle at registration and login - from the CAPTCHA to the password requirement - can have a direct effect on revenue here. A guest checkout, a magic-link sign-in and a login that allows password managers can 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.
Related Articles
Customers over 65: removing barriers in your online shop
Three in four people over 65 are online, and 76 per cent of them shop there. Which WCAG criteria slow this clientele down and in which order to fix them.
Accessible Product Pages: Variants, Gallery, Add to Cart
A flaw in the product template appears on every item page. How to make variant choice, gallery, price line and add-to-cart feedback accessible.
Accessible Withdrawal and Cancellation Buttons for Shops
Since 19 June 2026, § 356a BGB requires a withdrawal function. How it and the cancellation button work with keyboard, screen reader and zoom.