If your Monthly Audit report flagged an Accessible Authentication issue, it means your website includes login and verification flows that are unnecessarily hard. Some people with cognitive disabilities cannot solve puzzles, memorize a username and password, or retype one-time passcodes. WCAG 2.2 requires alternative options that make logins possible with less mental effort.

These issues can’t be fixed automatically by accessWidget, but there are clear ways your team can address it.

What is Accessible Authentication?

WCAG 2.2 introduced Accessible Authentication to address login and verification flows that are unnecessarily hard, especially for people with cognitive and memory disabilities.

There are two related success criteria:

• 3.3.8 Accessible Authentication (Minimum) – Level AA
• 3.3.9 Accessible Authentication (Enhanced) – Level AAA 

In short:

Users must be able to log in and authenticate without having to pass a difficult memory or puzzle-style test. If you do use such a test, you must also offer an accessible alternative or a mechanism that helps the user complete it.

WCAG calls this kind of challenge a cognitive function test, something that relies on memory, problem-solving, or complex transcribing.

Why it matters

For many users, login is the hardest part of using a website or app and can be a barrier for:

• Users with cognitive, memory, language, or learning disabilities who may struggle to remember complex passwords, follow multi-step puzzles, or understand tricky instructions.
• Users with attention difficulties (e.g., ADHD) who may lose track of steps in a multi-stage authentication flow.
• Users with dyslexia or low vision who may find it very hard to read and retype distorted text or long character strings.
• Users of assistive technologies may not be able to solve image or audio-based CAPTCHAs at all if they are not implemented accessibly.

From a legal/compliance perspective:

• 3.3.8 (Minimum) is Level AA and part of the standard expectations when conforming to WCAG 2.2 AA.
• 3.3.9 (Enhanced) is Level AAA and recommended as a best practice where possible.

Where this shows up on websites

Accessible authentication issues commonly appear in:

• Login and account creation forms: Forced complex password rules that reject pasted values or password managers
• Multi-factor and step-up authentication: Puzzle CAPTCHAs, Drag the slider to solve the puzzle, or slide the piece into place
• Fraud / bot prevention flows: Click all images showing cars, math or logic questions to prove you’re human

What the guidelines require

3.3.8 Accessible Authentication (Minimum) – Level AA

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

• Alternative: Another authentication method that does not rely on a cognitive function test.
• Mechanism: A mechanism that helps the user complete the test.
• Object / personal content recognition: The test only requires recognizing objects or user-provided content (e.g., picking a picture you previously chose).

Important clarifications:

• Allowing password managers, copy–paste, and ‘show password’ counts as a mechanism that reduces the cognitive burden (you’re not forcing the user to recall and retype from memory).
• Recognizing a familiar picture or other personal content the user provided (e.g., “pick the photo you uploaded”) can be acceptable for Level AA.

3.3.9 Accessible Authentication (No Exception / Enhanced) – Level AAA

Success criterion 3.3.9 extends the same idea without the exceptions.

Even object-recognition or personal-content tests shouldn’t be required unless there is an alternative or helping mechanism.

How you can mitigate Accessible Authentication issues

1. Avoid reliance on cognitive tests where possible (recommended)

Use authentication methods that don’t require the user to remember complex strings or solve puzzles in the first place, for example:

• Password managers allowed and not blocked
• One-time passcodes (email or SMS) as an alternative
• Magic links (’Sign in via email link’)
• Passkeys / WebAuthn / biometrics where appropriate

These methods greatly reduce memory load and are recommended by both security and accessibility experts.

2. If you still use passwords, make them usable

If passwords remain part of your login:

• Allow copy–paste into username and password fields.
• Don’t block password managers (no script tricks that prevent auto-fill).
• Provide a ‘show password’ toggle so users can visually verify what they typed.
• Keep instructions simple and clear, and avoid overly complex rules that are hard to understand (e.g., four different character categories with ambiguous error messages).

These meet the mechanism to assist requirement as they reduce reliance on memory and retyping.

3. Rethink CAPTCHA and bot checks

If you use CAPTCHA or similar:

• Prefer non-cognitive methods:
  • Risk-based / behavioral detection (server-side)
  • Device-based checks
  • Email/SMS verification or reCAPTCHA modes that don’t require solving visual puzzles
• If you must use a challenge:
  • Offer at least one alternative that doesn’t require complex visual/audio problem solving (e.g., accessible checkbox “I’m not a robot” or a simple one-click confirmation beyond just a puzzle).
  • Ensure it can be used with keyboard and screen readers.

4. Simplify multi-step flows

• Do not require people to re-enter information you already have (see 3.3.7 Redundant Entry – Level A).
• If you need extra verification (e.g., a security question), make sure:
  • It has a clear and simple alternative, or
  • The answer can be copied/pasted or stored (not only recalled from memory).

Developer guidance

Support assisted entry for passwords

• Don’t disable browser autocomplete/autofill on authentication fields.
• Allow copy–paste for all critical fields (password, one-time code).
• Add a show/hide password button that:
  • Is keyboard focusable
  • Has an accessible name (e.g. aria-label="Show password" / aria-label="Hide password").

Use semantic HTML and clear error handling

• Use <form>, <label>, <input> correctly with for / id associations.
• Provide clear, descriptive error messages near the fields and ensure they are announced by assistive technologies (e.g., using aria-describedby pointing to the error).

Design authentication that doesn’t depend on puzzles

• Avoid custom ‘drag to unlock’, ‘tile puzzles’, or ‘find the pattern’ widgets as the only way to proceed.
• If such a control exists, provide an equivalent non-puzzle route (e.g., one-time password, email link).

Consider passwordless and passkeys

Explore WebAuthn / passkeys which:

• Shift the burden of security to devices and platforms
• Remove the need to remember and type passwords
• Can drastically reduce cognitive load.