Accessible Two-Factor Authentication: Why Login Codes Lock People Out

You added two-factor authentication because it was the responsible thing to do. A password alone is not enough anymore, so now your customers type a six-digit code from a text message or an app before they get in. Safer. Sensible. Recommended by every security guide on the internet.

It is also one of the most common places a website accidentally locks disabled customers out completely — worse, in a way, than a missing alt text or a low-contrast button, because there is no way around it. A customer who cannot get past your verification screen cannot reach their account at all. They cannot buy, cannot rebook, cannot download what they already paid for, and cannot contact support from inside the account. The front door is locked and the doorbell is broken.

This guide is for the business owner or marketer, not the engineer. You do not need to read a line of code. You will learn exactly what goes wrong with two-factor authentication and login codes, how to test it yourself in a few minutes, and what to ask your developer or platform to change. We will also cover the part of WCAG 2.2 and the European Accessibility Act that was written specifically to stop logins from becoming an obstacle course — a rule that catches almost everyone by surprise.

What “two-factor” actually asks of a person

The idea behind two-factor authentication, or 2FA, is simple: prove who you are with two different things. Usually that is something you know (your password) plus something you have (your phone). After you type your password, the site sends a one-time code — by text message, email, or an authenticator app — and you type that code in to finish logging in.

For most people this takes ten seconds. But think about everything that small step quietly demands. You have to notice the code arrived. You have to read it. You have to remember six digits long enough to switch apps and type them. You have to type them accurately, often into a row of tiny separate boxes, before a timer runs out. Then, if you fat-finger one digit, you have to figure out what went wrong and start over.

Every one of those demands is a place where a poorly built verification screen can fail a real person — someone using a screen reader, someone with low vision, someone who navigates by keyboard, someone with a tremor, or someone with a memory or attention difference. The security is fine. The way it is built is the problem.

The six-box code input: a small design with a big accessibility cost

The single most common 2FA mistake is the fashionable row of separate single-character boxes — six little squares, one digit each, with the cursor jumping automatically to the next box as you type.

It looks clean and modern. It is also a minefield for assistive technology when built carelessly:

  • Screen readers get confused. Each box is often an unlabeled input, so a screen reader announces “edit, blank” six times in a row with no idea that these are pieces of one code. The user hears nothing that explains “enter your 6-digit code.”
  • The auto-advance fights the user. When focus jumps automatically after each digit, screen reader and keyboard users can lose track of where they are. Correcting a single wrong digit — pressing Backspace — behaves unpredictably, sometimes deleting the wrong box or refusing to move backward.
  • Pasting breaks. Many people copy the code from their messages and paste it. Split-box inputs frequently accept the paste into only the first box, or reject it entirely, forcing manual entry of every digit.
  • Auto-fill never fires. On a phone, the operating system can read an SMS code and offer to fill it in automatically — but only if the field is built to allow it. Split boxes usually block that help, removing a feature that disabled users rely on most.

None of this means you cannot use a code entry screen. It means a single, normal text field is almost always better than six clever ones. One labeled box — “Enter the 6-digit code we sent you” — that accepts a typed code, a pasted code, and an auto-filled code works for everyone and is far harder to get wrong.

The fixes that matter most

Here is what to ask your developer or platform to do. You can hand this list over as-is.

Use one labeled field, or label every box. Prefer a single input with a visible label and a clear instruction. If the design truly requires separate boxes, each one needs a hidden accessible label, the group needs a single description, and the whole thing must behave as one control to assistive technology.

Let people paste and auto-fill. The field should accept a pasted six-digit code into any position and fill all the digits. On the technical side, the input should be marked so phones can offer the texted code automatically — developers know this as the “one-time-code” autofill hint. This one change removes more friction than any other.

Make Backspace and editing predictable. A person must be able to move back, fix one wrong digit, and try again without the cursor jumping around or the field wiping itself. If correcting a mistake is harder than starting over, the design has failed.

Announce errors out loud. When a code is wrong or expired, the message must be real text that a screen reader reads automatically — not a red border, not a color change, and not a message that flashes and vanishes. “That code has expired. We have sent a new one” should be announced the moment it appears.

Be generous with time. Codes that expire in 30 or 60 seconds punish anyone who reads slowly, switches between apps, or uses a screen reader to find the digits. Give a realistic window, make the “resend code” button easy to find and clearly labeled, and never silently reset the timer.

Offer more than one path. Phone-only verification assumes everyone can receive and read a text quickly. Offer a choice — authenticator app, email, or text — and a documented recovery route for people who lose access to one method.

The WCAG 2.2 rule that catches everyone: Accessible Authentication

In 2023, the Web Content Accessibility Guidelines added a new rule at version 2.2 called Accessible Authentication (success criterion 3.3.8), and it is one of the most commonly overlooked requirements in the whole standard. Because the European Accessibility Act and most modern accessibility laws point at WCAG, this rule applies to the products those laws cover.

In plain English, the rule says this: you must not force someone to pass a cognitive test — to remember, transcribe, or solve a puzzle — as the only way to log in, unless you provide an alternative or the step can be handled automatically.

That sounds abstract until you see what it bans in practice:

  • You cannot require people to memorize a code and retype it from memory with no ability to paste it. (So copy and paste must work.)
  • You cannot require people to transcribe something by hand if a more accessible option exists.
  • You cannot block password managers or browser auto-fill, because those are exactly the assistive tools that let people avoid memorizing things.
  • You cannot make a puzzle — “select all the traffic lights,” “what is 7 plus 4,” “drag the slider” — the only gate to entry.

Two-factor codes sit right in the firing line. A six-digit code is fine; requiring someone to read it from one screen and key it in from memory, with pasting disabled and a 30-second timer, starts to look like exactly the cognitive obstacle the rule was written to remove. The fix is the same as the good practice above: allow pasting and auto-fill, give enough time, and never disable the tools people use to get around their own memory.

This is also why “prove you are human” puzzles deserve a hard look. If your login or checkout throws a distorted-text or image puzzle at people, that can fail both this authentication rule and basic usability for blind and low-vision users. There are accessible alternatives, and we cover them in a dedicated guide linked below.

How to test your own login in five minutes

You do not need special software to find most of these problems. Try this on your own site:

  1. Log out and log back in. Go all the way through your real verification screen. Notice how many steps it takes and how tight the timer feels.
  2. Try to paste the code. Copy the six digits from your messages and paste them into the field. Do all the digits land? If only the first box fills, you have found a problem.
  3. Make a deliberate mistake. Type a wrong digit, then try to fix just that one digit with Backspace. Does it behave sensibly, or do you have to start over?
  4. Put the mouse away. Reach the code field and submit using only the Tab key, arrow keys, and Enter. If you get stuck, so do keyboard users.
  5. Turn on the screen reader. On a Mac, press Command + F5 to start VoiceOver; on Windows, NVDA is a free download. Close your eyes and try to complete the login by ear alone. If the field is silent or just says “edit, blank,” your customers who are blind hear the same nothing.

If any of these stops you, it stops a paying customer too — and at the login screen, a stopped customer is a lost one.

Why this is worth your attention now

Two-factor authentication is only getting more common. Payment rules, data-protection expectations, and plain good security are pushing more businesses to add a verification step, which means more login screens, more code fields, and more chances to lock people out without realizing it. Because the verification screen sits at the very front of the experience — before the cart, before the account, before support — a failure here costs you the entire customer, not just one page.

The good news is that the accessible version is also the easier, friendlier version for everyone. One clear field instead of six fiddly boxes. Pasting that works. Enough time to read. Errors you can actually understand. Nobody has ever complained that a login was too easy to complete.

You do not have to weaken your security to do any of this. Strong authentication and accessible authentication are the same goal seen from two angles: letting the right person in, smoothly, without putting an unnecessary obstacle in their way.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.