Accessible Login and Password Fields: The Front Door Most Websites Lock

Think about the first thing a returning customer does on your website. They do not browse. They do not read your blog. They log in. The login form is the front door, and for a surprising number of people, that door is locked.

Login and sign-up forms fail accessibility tests more often than almost any other part of a website. That is partly because they are deceptively simple — an email box, a password box, a button — and partly because the “clever” extras we bolt on (password strength meters, “show password” eyes, copy-paste blocking, puzzle challenges, one-time codes) tend to be built for looks rather than for the keyboard and the screen reader. When the front door does not work, nothing behind it matters. A customer who cannot log in cannot buy, cannot rebook, cannot download what they already paid for.

This guide is for the business owner, not the engineer. You do not need to read code to follow it. You will learn what goes wrong with login forms, how to spot it yourself, and what to ask your developer or platform to fix. Along the way we will cover the one part of the European Accessibility Act and WCAG 2.2 that is brand new and catches almost everyone off guard: the rule about not making people solve a puzzle just to prove who they are.

Why login forms matter more than they look

There is a legal reason and a human reason, and they point the same way.

The legal reason: the European Accessibility Act (EAA), which began applying in June 2025, and the Americans with Disabilities Act both treat your whole customer journey as something that must be usable by people with disabilities. The technical benchmark almost everyone uses is WCAG — the Web Content Accessibility Guidelines — at Level AA. A login screen is squarely in scope. If a blind customer can browse your shop but cannot get past the sign-in page, you have an accessibility failure at the most critical point in the funnel, and it is exactly the kind of barrier that shows up in complaints and demand letters.

The human reason: authentication is stressful for everyone, and far more so if you have low vision, a motor impairment, dyslexia, or a memory-related disability. A password is a string of random characters you cannot see, typed into a box that hides what you type, often under a time limit, sometimes followed by a code you have fifteen seconds to copy from a text message. Every extra hurdle multiplies the chance that someone gives up. Accessibility fixes here do not just help disabled users — they reduce abandonment for everyone.

The most common login failures (and how to spot them)

You can find most of these yourself in about ten minutes, using nothing but your keyboard.

1. Inputs without real labels

Every field needs a visible, programmatically connected label — the word “Email” or “Password” that a screen reader reads aloud when the cursor lands in the box. Designers love the minimalist look where the label lives inside the field as grey placeholder text and disappears the moment you start typing. That fails two ways: the placeholder vanishes, so people forget what the field was for, and many screen readers do not announce placeholder text reliably as a label.

How to check: Click into the email box. Is there a visible label that stays put above or beside the field? Now press Tab to move through the form using only your keyboard. If a field has only faint grey text inside it and nothing else, flag it.

The fix in plain terms: ask for visible, persistent labels on every field, connected to the input so assistive technology announces them. Placeholders can stay as hints, but they are never a substitute for a label.

2. The “show password” eye that no one can use

The little eye icon that reveals your password is genuinely helpful — typing a complex password blind is hard for everyone and brutal for people with motor or vision disabilities. WCAG actually encourages letting people see what they typed. But the icon is almost always built as a decorative graphic with no accessible name, so a screen reader announces “button” with no clue what it does, and it frequently cannot be reached or triggered with the keyboard at all.

How to check: Tab to the password field, then Tab again. Can you reach the show/hide control with the keyboard and activate it with the Enter or Space key? Turn on your screen reader (VoiceOver on Mac, Narrator on Windows) and listen — does it say something like “Show password, button,” or just “button”?

The fix: the toggle must be a real, keyboard-reachable button with a clear name like “Show password,” and that name should update to “Hide password” when the text is visible.

3. Blocking paste in the password field

To force “security,” some sites disable pasting into the password box. This is one of the most user-hostile things a login form can do. People who rely on a password manager — which is the single best security practice there is — suddenly cannot fill the field. For someone with a motor disability, hand-typing a 20-character password instead of pasting it is not a minor annoyance; it can be the difference between getting in and not. Security experts have been telling people to stop doing this for years, and accessibility makes the case even stronger.

How to check: copy any text, click into the password field, and try to paste. If it refuses, that needs to change.

4. Error messages that only work if you can see red

When login fails, a lot of sites turn the field border red and leave it at that, or show a vague “incorrect login.” Color alone is not enough — a colorblind or blind user gets no signal at all. The error needs to be real text, placed where it makes sense, worded so a person actually knows what to do, and announced to screen reader users when it appears.

How to check: deliberately enter a wrong password and submit. Is there clear text explaining the problem? Does it say something useful, or just “Error”? Would you know what went wrong if the screen were greyscale?

The fix: pair every error with descriptive text (“We could not find an account with that email”) and make sure the message is announced, not just shown. Avoid leaking which half was wrong in a way that helps attackers, but never hide the fact that something failed.

5. Tiny tap targets and cramped controls

On phones, the “Forgot password?” link, the checkbox for “Remember me,” and the show-password eye are often tiny and jammed together. WCAG 2.2 added a rule that interactive controls should be at least 24 by 24 CSS pixels, or have enough spacing around them, precisely because small, crowded targets are unusable for people with tremors or limited dexterity.

How to check: open the login page on your phone and try to tap each control with your thumb without zooming. If you keep hitting the wrong thing, so do your customers.

The new rule everyone misses: Accessible Authentication

Here is the part that is genuinely new, and the reason this topic deserves its own article in 2026.

WCAG 2.2, published in late 2023 and now the practical reference point for EAA and ADA expectations, introduced a success criterion called Accessible Authentication (3.3.8). In plain English it says: you must not force people to pass a “cognitive function test” to log in — unless there is an accessible alternative. A cognitive function test means anything that asks the brain to remember, transcribe, calculate, or solve a puzzle.

That sweeps in a lot of common patterns:

  • Remembering a password from memory with no other option. The accessible answer is simple: allow password managers and allow paste. If a manager can fill it, the user is not being tested.
  • Transcribing a code by hand. “Enter the 6-digit code from your authenticator.” If the only way is to read it and retype it from memory, that is a transcription test. Letting people copy and paste the code, or supporting one-tap email links and passkeys, satisfies the rule.
  • Solving a puzzle CAPTCHA — “select all the traffic lights,” or unscrambling distorted letters — as the gate to log in. These are cognitive tests by definition. You need an accessible path that does not rely on recognizing images or remembering things.

The friendliest way to comply is also the most modern: support passkeys and password managers, let people paste codes and passwords, and offer email magic links as an alternative. Each of these removes a memory or transcription burden instead of adding one. If you use a two-factor step, make sure the code can be pasted and that the input does not silently clear itself if the user is a few seconds slow.

This criterion surprises people because it runs against a decade of “security theater” instincts — the belief that friction equals safety. It does not. Blocking paste and forcing puzzle CAPTCHAs make accounts less secure (people pick weaker, memorable passwords) and shut out disabled users at the same time. WCAG 2.2 simply codifies what good security teams already knew.

A 10-minute login audit you can run today

You do not need tools or training for a first pass. Open your own login page and:

  1. Tab through it. Reach every field, link, checkbox, and the show-password toggle using only the keyboard. Can you see a clear outline showing where you are? Can you submit with the Enter key?
  2. Read the labels. Does every box have a visible label that stays put, not just placeholder text?
  3. Test paste. Paste into both the password field and any verification-code field. It must work.
  4. Break it on purpose. Enter a wrong password. Is the error clear text, with a useful message, not just a red box?
  5. Try it on your phone. Can you tap every control with your thumb, including “Forgot password?” and the eye icon?
  6. Listen to it. Turn on VoiceOver or Narrator for two minutes and walk through the form. Anything that announces as a bare “button” or “edit text” with no name is a problem.

Write down what fails. That list is your brief for whoever maintains the site — and most of these are small, cheap fixes, not rebuilds.

The bottom line

A login form is not where you should be clever. It is where you should be boring, predictable, and forgiving. Visible labels, a keyboard-reachable show-password button, working paste, plain-language errors, generous tap targets, and support for password managers and passkeys will get you past the vast majority of failures — and past the new WCAG 2.2 authentication rule that trips up nearly everyone. Fix the front door first. Everything you have built behind it depends on people being able to walk through.

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