Signing in should be the least interesting part of visiting any website today. For many customers, it is the hardest. They are asked to remember a long password they set years ago, retype a code from another device before it expires, pick out every square containing a traffic light or decode a string of warped letters. Each of these steps assumes a certain kind of memory, vision, attention and dexterity. When those assumptions fail, the customer is locked out of their own account.

Accessible authentication means designing logins that do not depend on solving puzzles or recalling information from memory. It matters for people with cognitive disabilities, for older customers, for people using screen readers or voice control and for anyone who is tired or in a hurry. This guide explains what the accessibility standard asks for, how current security guidance lines up with it and how to redesign customer logins so they are both safer and easier to use.

This article is general information, not legal advice. If you have specific compliance obligations, talk with qualified counsel.

What the standard asks for

The Web Content Accessibility Guidelines version 2.2 added two success criteria about authentication. The WCAG 2.2 Recommendation, published by the W3C on 5 October 2023, includes success criterion 3.3.8, Accessible Authentication (Minimum), at Level AA.

It states that 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 four things:

  • An alternative: another authentication method that does not rely on a cognitive function test.
  • A mechanism: something available to assist the user in completing the test.
  • Object recognition: the test is to recognize objects.
  • Personal content: the test is to identify non-text content the user provided to the website.

The criterion’s notes give examples of mechanisms that satisfy it: support for password entry by password managers to reduce memory need, and copy and paste to reduce the cognitive burden of re-typing. A related criterion, 3.3.9 Accessible Authentication (Enhanced), sets a stricter bar at Level AAA by removing the object recognition and personal content exceptions.

In plain terms, a password login can conform if people can use a password manager and paste into the field. A puzzle CAPTCHA can be a barrier unless there is another route through. Blocking paste, disabling autofill or forcing people to transcribe codes by hand are the patterns most likely to fail.

Security guidance points the same way

Teams sometimes assume accessibility and security pull in opposite directions. Current federal guidance suggests otherwise.

The National Institute of Standards and Technology published the final version of SP 800-63B-4, its digital identity guidelines on authentication, in July 2025. Although written for federal agencies, it is widely read as a reference for good practice. Several of its password requirements line up closely with accessible design:

  • Verifiers shall allow the use of password managers and autofill functionality.
  • Verifiers should permit claimants to use the paste function when entering a password.
  • Verifiers shall not impose other composition rules, such as requiring mixtures of different character types.
  • Verifiers shall not require subscribers to change passwords periodically, though they shall force a change if there is evidence that the authenticator has been compromised.
  • Verifiers shall not prompt subscribers to use knowledge-based authentication or security questions, such as asking for the name of a first pet, when choosing passwords.
  • Passwords used as a single-factor authentication mechanism must be a minimum of 15 characters in length, and verifiers should permit a maximum length of at least 64 characters to support passphrases.

The guidelines note that password managers have been shown to increase the likelihood that people will choose stronger passwords. They also require that verifiers offer at least one phishing-resistant authentication option at the second authentication assurance level, and they include a normative appendix on syncable authenticators, the category that includes most consumer passkeys.

The direction is clear: fewer memory tests, more support for tools that remember for the user and stronger methods that resist phishing.

An older woman in an aqua cardigan holds a small purple USB security key beside a closed laptop.

Passkeys and the move away from passwords

Passkeys let people sign in with the same fingerprint, face scan or device PIN they use to unlock their phone or computer. There is nothing to remember or type, and the credential is tied to the real website, which makes it far harder to steal through a fake login page.

Adoption is growing. In a World Passkey Day 2025 announcement dated May 1, 2025, the FIDO Alliance reported survey results showing that 74 percent of consumers are aware of passkeys and 69 percent have enabled them on at least one of their accounts. The same research found that 47 percent of consumers will abandon purchases if they have forgotten their password for that particular account, and that over 35 percent of people had at least one account compromised due to password vulnerabilities in the past year. The survey was an online poll of 1,389 adults across five countries conducted in April 2025, so treat the figures as a broad indication rather than a precise measure for your own customers.

For a store or membership site, that abandonment figure is the point. A forgotten password is not just an accessibility problem. It is a lost sale.

Common login barriers to remove

Review your sign-in, sign-up, password reset and checkout flows for these patterns:

  • Blocked paste. Fields that prevent pasting break password managers and force people to retype long strings.
  • Disabled autofill. Autocomplete attributes turned off, or fields named in ways browsers cannot recognize, stop saved credentials from filling.
  • Puzzle CAPTCHAs. Distorted text, image grids and drag puzzles are difficult or impossible for many people, especially with screen readers or motor impairments.
  • Short code timeouts. One-time codes that expire before someone can switch apps and type them create repeated failures.
  • Split code fields. Six separate boxes for a six-digit code often break paste and confuse assistive technology.
  • Strict composition rules. Requirements for symbols, numbers and capitals produce passwords people cannot remember and do not make them meaningfully stronger.
  • Security questions. Questions about personal history are a memory test and are often easy for attackers to research.
  • Hidden errors. Messages that do not say what went wrong, or are not announced to screen readers, leave people guessing.

Better patterns for customer accounts

The goal is to offer at least one path through every login step that does not rely on memory or puzzles.

  1. Allow paste and autofill everywhere. Use standard input types and autocomplete values such as username, current-password and one-time-code so browsers and password managers work.
  2. Offer passkeys. Let customers add a passkey after signing in, and offer it as the default on devices that support it.
  3. Provide email magic links or codes that can be pasted. Make sure codes last long enough and can be filled automatically on phones.
  4. Replace puzzle CAPTCHAs. Use invisible risk checks, rate limiting and bot detection that does not ask the customer to solve anything. If a challenge is unavoidable, provide an accessible alternative.
  5. Show the password. A show password toggle reduces typing errors for everyone.
  6. Write clear error messages. Explain what went wrong and how to fix it, and make sure the message is announced to assistive technology.
  7. Support guest checkout. Not every purchase needs an account.

Our UI and UX design team treats sign-in as part of the customer journey rather than a security checkpoint bolted on at the end.

A man in a purple shirt types on a laptop wearing earbuds while a woman in an orange sweater takes notes.

Do not forget account recovery

Many sites fix the main login and leave password reset untouched. Recovery is often where the hardest barriers hide, because it is designed for the moment when someone has already forgotten something.

Look at every step of your reset flow. If it asks security questions, it is testing memory. If it sends a code that expires in a minute or two, it penalizes anyone who needs more time to switch apps. If it requires a new password that meets complex rules, it sets the customer up to forget again. Recovery should rely on something the customer has, such as access to an email address, phone or registered device, rather than something they must remember.

Test with real people and real tools

Automated checkers can spot missing labels, but they rarely catch an expired code or a blocked password manager. Test your login and recovery flows by hand:

  • Sign in using a password manager on desktop and mobile.
  • Paste a password and a one-time code into each field.
  • Complete the flow with a screen reader and with keyboard only.
  • Try voice control or switch access if you can.
  • Trigger every error and check that it is clear and announced.
  • Go through password reset from start to finish.

Check the flows on small screens too. Login forms that look fine on a laptop can push buttons off screen or hide error messages on a phone. Our responsive design work includes testing authentication on a range of devices.

Whenever possible, include people with disabilities in testing. They find barriers no checklist predicts.

Where to start

If a full redesign is not possible right away, begin with the changes that remove the most friction for the least effort. Allowing paste and autofill is usually a small code change. Removing composition rules and forced password changes is a policy decision more than an engineering one.

Next, look at CAPTCHAs and code timeouts, which typically involve a third-party service or configuration change. Passkeys take more planning, but most modern identity platforms and frameworks now support them, and can be added gradually.

A fictional example

Consider a fictional online bookstore that noticed a steady stream of support emails from customers unable to sign in. The login form blocked paste, the checkout used an image-grid CAPTCHA and password reset codes expired after two minutes.

The store’s team allowed paste and autofill, replaced the CAPTCHA with background bot detection and rate limiting, extended code lifetimes and added the one-time-code autocomplete value so phones could fill codes automatically. They then offered passkeys to signed-in customers. Within a few months, login-related support requests dropped noticeably, and several longtime customers wrote to say they could finally manage their accounts without help from a family member.

An accessible authentication checklist

  • Paste works in every password and code field.
  • Autofill and password managers work on every login form.
  • Passkeys are offered to customers.
  • No puzzle CAPTCHA appears without an accessible alternative.
  • One-time codes last long enough and can be pasted or autofilled.
  • Composition rules and periodic password changes are removed.
  • Security questions are not used.
  • Errors are clear and announced to assistive technology.
  • Flows are tested with screen readers, keyboard only and on mobile.
  • Guest checkout is available.

Accessible logins respect the customer’s time and abilities while improving security. For a broader review of your site, explore our website accessibility services.