Ramona-Schwering_square

Ramona, a Developer Advocate at Auth0, bridges roles as a tester and developer. She's a Google Dev Expert in Web Tech, Women Techmaker Ambassador, and Cypress Ambassador, building trust in test automation and identity topics.

Developer Advocate

Ramona Schwering

WCAG 3.3.8 sets minimum standards for accessible authentication. 3.3.9 enhances these by removing exceptions and automating cognitive tests for users.

An Accessible Guide to WCAG 3.3.9: Going for Gold

Logging in can be tough for users with cognitive disabilities. WCAG's Success Criterion 3.3.8, "Accessible Authentication," provides guidance.



Creating a login page that includes fields for a username and password and options for social login sounds simple. However, this standard setup can actually trip up many users. Developers often miss the hurdle of ensuring everyone can log in easily, and that oversight can have significant consequences. The challenge of making authentication accessible to everyone is a common blind spot.

Remember this: It’s somewhere between annoying and stressful to have a forgotten password, a complex CAPTCHA, or a one-time code you must quickly memorize and type from another device. For many people, these things are mildly annoying, but for someone with a memory impairment, dyslexia, or even just high anxiety, they can be a blocker. When your login flow demands these cognitive efforts, you are not just creating friction but actively excluding people. So, how can you solve this?

## First things first: Understanding WCAG 3.3.8

Fortunately, we’re not alone here: The [WCAG 2.2](https://www.w3.org/TR/WCAG22/) update brought us [Success Criterion 3.3.8](https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html), "Accessible Authentication (Minimum)," to address this exact problem. The core idea is straightforward: a cognitive function test isn’t required for any step in an authentication process unless you also offer an accessible alternative or a helping mechanism. Using any kind of object recognition and identifying personal content should also be avoided.

But what is a "cognitive function test?" While it may sound complicated, it is really just anything that requires a user to do one of the following:

* **Memorize information**, like a username and a password.  
* **Transcribe information**, for example, typing a one-time code from their phone into a form on their computer.  
* **Solve a puzzle**, like those "select all the traffic lights" CAPTCHA.

You see, the main goal is to lower your users' cognitive load. These tasks can be demanding for people with dyslexia, memory issues, or high anxiety. Giving them alternative options creates a much more inclusive and welcoming experience.

## The common pitfalls: What authentication methods fail this test?

Many of the login methods you see every day are actually cognitive tests. The first step to fixing them is to recognize them. Without an alternative, these methods would fail the test:

* **Standard username and password fields:** The most common login method is a memory test. If a user has to remember and type their credentials from memory, it's a cognitive test.  
* **Transcription-based two-factor authentication (2FA):** If you send a user a 6-digit code via SMS and make them type it into your website, requiring transcription.  
* **Blocking copy-paste:** Some websites turn off the paste function in password fields for “security reasons”. 🙈 This is a major accessibility failure. It forces transcription and blocks people from using their password managers.

One typical part of authentication that fails two core principles simultaneously is [CAPTCHA](https://en.wikipedia.org/wiki/CAPTCHA), which deserves an honorable mention. Asking users to figure out distorted text or solve a visual puzzle greatly strains their processing abilities. While speaking with an attendee at a conference, I found this one:  


<picture>
<img src="https://cdn.auth0.com/website/blog/captcha-wcag.png" alt="Example of a captcha" style="width:30%; margin: 10px auto;">
</picture>

At best, it’s annoying, and at worst, it’s impossible to solve for people with cognitive disabilities. 

## Five ways to build accessible and compliant logins

So, how do you fix this? You should start by looking at your entire authentication flow, from start to finish. At every step, you should ask yourself: "Am I requiring the user to remember, transcribe, or solve something?" If the answer is yes, you must ask, "Am I providing an alternative?" The key here is offering alternative methods that don't depend on these abilities. The solutions often align with modern best practices for authentication anyway. Let's get started\! 🙌

### 1\. Go passwordless

Instead of making passwords and their handling easier, it’s even better to get rid of them completely. **[Passwordless authentication](https://auth0.com/docs/authenticate/passwordless)** is more accessible because it removes the memory test passwords usually require.

Good options include:

* **Magic links**: Sending a single-use login link to a user's email is a fantastic and accessible alternative. The user just needs to click a link, not remember or type anything.  
* **Social login:** Letting users log in with their existing Google, GitHub, or other accounts passes the authentication work to a provider they already use and trust

### 2\. The modern standard: Leverage WebAuthn via passkeys

For the best combination of security and accessibility, **[WebAuthn](https://auth0.com/docs/secure/multi-factor-authentication/fido-authentication-with-webauthn) (Web Authentication)** is the answer, which includes its user-friendly implementation of **[passkeys](https://auth0.com/docs/authenticate/database-connections/passkeys)**. Instead of using a password, passkeys use public-key cryptography. This method creates a unique key pair for each site, which is stored securely on the user's device.

<picture>
<img src="https://images.ctfassets.net/23aumh6u8s0i/4cwVRfb5J5sdlJonMOY8M/fd077197f168fcbfed536bfdd3824a2b/passkeys_launch_hero_image.jpg" alt="passkey illustration" style="width:50%; float:right; margin: 0px 30px 30px 30px;">
</picture>

Users can log in via passkeys using biometrics, such as fingerprints, Apple’s FaceID, or a physical security key.

Thanks to passkey providers like Google, Apple, and 1Password, these credentials can sync across a user's devices. This method completely replaces the need for passwords and cognitive tests with a simple, secure action. That way, they don’t need any passwords to remember or one-time codes to transcribe. It’s the gold standard for creating a login flow that is both incredibly secure and fundamentally accessible.

### 3\. Re-thinking your multifactor authentication (MFA)

MFA is a fantastic layer of security, but you must be careful with how you implement it. If your primary MFA method sends a six-digit code via SMS ([OTP](https://auth0.com/blog/what-is-a-one-time-password-otp/)) that the user must manually type into your website, you are requiring transcription. This is another cognitive test that can be a barrier for some users. 

The solution is to provide more accessible alternatives that don't rely on transcription. For example, you can offer MFA, which uses push notifications, biometrics through WebAuthn, or physical security keys to ensure your application is secure and accessible. You maintain a high level of security this way, without creating an unnecessary hurdle for your users. If you need to stick to OTPs, avoid context switching where possible. While often unavoidable for MFA, minimizing the need to jump between different devices or apps (e.g., sending an SMS code to the device you're already on) reduces the cognitive load.  
Where possible (e.g., on mobile, for SMS OTPs), facilitate auto-copy or provide a "copy code" button. Furthermore, if using time-based one-time passcodes (TOTPs) from authenticator apps or SMS, ensure the time limit is generous enough (at least 60 seconds, preferably longer) for users with cognitive or motor disabilities to read and enter the code.

Additionally, you already need to be careful when prompting the user to configure MFA. If QR codes are used for authenticator app setup, always provide the text-based secret key as an alternative for users who cannot scan the QR code. It’s not enough to hide it in an obscure button; always store it in a way a screen reader can handle.

### 4\. Handle captchas carefully

If you cannot avoid using a CAPTCHA, please be mindful of its accessibility. While the guidelines suggest that simple object recognition (e.g., "select all images with a car") is fine, even these can be significant cognitive tests, as the user still needs the mental capacity to solve them. Those visual puzzles can be confusing, culturally biased, or impossible to solve for people with cognitive disabilities.

Therefore, always remember to provide accessible alternatives. AS a starting point, this includes non-visual options like audio challenges, but they are still often difficult for users. A better approach is to move toward a modern, privacy-respecting, and invisible CAPTCHA. The most well-known example is [**Google's reCAPTCHA v3**](https://developers.google.com/recaptcha/docs/v3). This invisible CAPTCHA operates in the background, analyzing user behavior to generate a risk score. Developers can then use this score to determine whether a user can proceed or should be blocked.

These systems work in the background by analyzing user behavior and device signals to assess risk, intervening only when a threat is likely. This approach avoids presenting a cognitive challenge to the user altogether, creating a much smoother and more inclusive experience.

### 5\. Embrace password managers and copy-paste

This is the simplest and most important step you can take: allowing the use of password managers is the easiest way to make a traditional login form accessible.  

For your application, this means two key things:

* Most importantly, **never, ever block \`paste\` functionality** on your input fields. This feature usually lets users copy their credentials from a password manager or a document and paste them.  
* Use proper HTML attributes, as seen in the following example. This helps browsers and password managers correctly fill the fields.

```html
<label for="username">Username:</label>
<input type="text" id="username" name="username" autocomplete="username">

<label for="password">Password:</label>
<input type="password" id="password" name="password" autocomplete="current-password">
```

#### Important note on clickjacking with password managers

Promoting the use of password managers is super important. However, it's also important to be mindful of potential attack vectors in that area. A recent example comes from [clickjacking](https://auth0.com/blog/preventing-clickjacking-attacks/). This technique involves a malicious or compromised webpage visually disguising or overlaying elements of a page or browser extension, like the autofill menu, so that a user unintentionally clicks on them. In recent weeks, a vulnerability has been uncovered that allows a malicious website to have those exact, invisible overlays. This can deceive users into responding to a hidden prompt from 1Password, potentially leading them to accidentally autofill sensitive information, such as credit card numbers. 1Password [wrote an instructive blog post](https://blog.1password.com/clickjacking-what-it-means-for-1password-users/) on this vulnerability, explicitly stating that autofill should still stay turned on and be used. However, it's a great reminder to keep following security best practices and stay updated on information from security researchers and password manager vendors to protect users effectively.

## Accelerating your solution: When to build vs. buy

These solutions are clear, but implementing and maintaining many different authentication flows is a lot of work. Password-based, passwordless, social, and WebAuthn all require significant development effort. The classic "build vs. buy" dilemma can really slow you down your progress.

This is where you can speed up your path to an accessible solution by using a dedicated identity platform instead of building it all from scratch. Experts' pre-built components are often the most efficient way to solve this challenge.

* To achieve compliance quickly, a service like Auth0's [Universal Login](https://auth0.com/docs/authenticate/login/auth0-universal-login) provides an accessible login page that is compliant out of the box. It automatically supports password managers, social logins, passwordless options, and accessible MFA methods.  
* If you need more control over the UI, you can use tools like the Auth0 Labs’ [UI components](https://a0.to/ui-content). These are single, accessible components you can put directly into your application. This gives you a custom login experience while still using a robust and secure backend.

## Conclusion

Building accessible authentication is not just about a WCAG compliance checkbox. It is about respecting your users and ensuring everyone can use your application without being frustrated or literally locked out.

Move away from traditional methods that rely on cognitive tests and adopt modern, user-friendly alternatives. This approach makes your application accessible to all users while enhancing security and usability. It's a win-win situation that fosters trust and demonstrates your commitment to creating a genuinely inclusive digital world.❤️  


"accessible authentication"