Login forms, one-time codes and CAPTCHAs: WCAG 2.2 Accessible Authentication for small-business sites

If your website has a login, such as a client portal, a member area, a customer account on your online store or a booking account, WCAG 2.2 added a rule just for it: Success Criterion 3.3.8 Accessible Authentication (Minimum), level AA. The W3C sums it up as: don't make people solve, recall or transcribe something to log in. It matters because some people with cognitive disabilities, dyslexia or memory difficulties can't reliably memorise a password, retype a code or solve a puzzle.

What the rule says, in plain English

Remembering a password, typing characters you're shown, doing a sum or solving a puzzle all count as a "cognitive function test". A login step can use one only if it also gives people help or another way in. The W3C's own examples of acceptable help are letting password managers fill the fields and letting people copy and paste. Other ways in that pass include an email sign-in link, signing in with a passkey or the device's fingerprint or face unlock, and signing in with a third-party account (for example Google). CAPTCHAs that ask you to recognise common objects, such as "pick every picture with a car", are allowed at AA, but maths puzzles and distorted-text CAPTCHAs are not, unless there's another way through.

The rule covers logging in to an existing account, including every step of two-factor sign-in and account recovery. It doesn't cover creating the account, though the same fixes help there too.

1. Never block paste or password managers

The most common failure is a script that stops people pasting into the password or code field, or that turns off autofill. The W3C lists this as failure F109. Remove any onpaste="return false", paste-blocking script or autocomplete="off" on login fields, and mark the fields up so browsers and password managers recognise them (W3C technique H100):

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="username">
<label for="pw">Password</label>
<input id="pw" name="password" type="password" autocomplete="current-password">
<button type="button" aria-pressed="false" aria-controls="pw">Show password</button>

A "Show password" button isn't required by 3.3.8, but the W3C recommends it because hidden characters make typing harder. On a "create password" form use autocomplete="new-password" so the password manager offers to save it.

2. One-time codes: one field, paste allowed

Six separate boxes for a 6-digit code often break paste: only the first digit lands. Use one field that accepts the whole code and lets the phone fill it from a text message:

<label for="code">6-digit code from your text message</label>
<input id="code" name="code" inputmode="numeric" autocomplete="one-time-code" maxlength="6">

Better still, offer an option that needs no typing at all, such as an emailed sign-in link or a passkey.

3. CAPTCHAs on logins

• Avoid distorted-text and maths CAPTCHAs on login and recovery steps unless there's another way in. An audio version that people must transcribe doesn't count as that other way, according to the W3C.
• Prefer checks that run in the background, and use the W3C's suggestions to show a CAPTCHA less often: rate-limiting sign-in attempts and similar behind-the-scenes checks.
• Remember that a CAPTCHA that only appears after a wrong password or for people with ad blockers still counts.

4. CAPTCHAs on contact and booking forms

A contact form isn't a login, so 3.3.8 doesn't apply there, but a CAPTCHA is still a barrier for many people. WCAG's 1.1.1 Non-text Content asks that a CAPTCHA has a text alternative saying what it is for, and that an alternative form is offered (for example, visual and audio versions). The simplest fix for most small businesses: use a background spam check or a hidden honeypot field instead, and always show a phone number and email address next to the form so nobody is stuck. See accessible contact forms.

5. Third-party portals and booking accounts

Many small businesses use a portal they don't control: a patient portal, a tax-client portal, a gym members' app or a store platform's customer accounts. Run the self-test below on it, and if it fails, ask the vendor whether paste and password managers work on every step and whether they offer an email-link or passkey option. Ask for their accessibility conformance report (often called a VPAT). Until it's fixed, offer a phone alternative for anything people would normally log in to do.

A 5-minute self-test

1. Save your test login in a password manager or your browser. Does it fill the email and password automatically?
2. Copy the password from a notes app and paste it in. Does it paste?
3. Trigger a one-time code. Can you paste the whole code into the field in one go?
4. Enter a wrong password three times. Does a puzzle CAPTCHA appear, and is there another way through?
5. Click "Forgot password". Can you recover the account without memorising or retyping anything other than your email?
6. Tab through the whole login with the keyboard (our keyboard test) and check that errors say what went wrong.

What a scan can and can't check here

An automated scan like ours (axe-core) checks the code: login fields without labels, invalid autocomplete values, unnamed "show password" or submit buttons and low-contrast error text. It can't tell whether a script blocks paste, whether a code arrives and pastes cleanly, or whether a CAPTCHA appears after failed attempts, and it can't log in to your portal. Those need the 5-minute test above. Our free scan and Fix-Pack check public pages only.

This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.

Want the fixes written for you?

Start with a free homepage snapshot. The $149 Fix-Pack scans up to 10 pages and gives copy-paste fixes for your platform within 48 hours, with a 14-day refund promise. See a sample report first.

This is general technical guidance, not legal advice, and it does not certify compliance with the ADA or any law.

Related guides

• WCAG 2.2 explained for small-business websites
• Squarespace accessibility fixes: alt text, contrast, forms and more
• Wix accessibility fixes: a practical checklist
• WordPress accessibility fixes (block editor and themes)

All guides

This guide is general technical information, not legal advice. Following it does not certify ADA or any legal compliance. Automated checks find only part of accessibility barriers.