Here's a fix you can ship before lunch: add a show/hide toggle to your password field. That's it. One button, one aria-label, maybe fifteen minutes of work if your design system already has an icon for it. And it directly addresses something WCAG calls out by name as a barrier to logging in at all.
Most teams treat masked password fields as a security default nobody questions. But a masked field with no way to check what you typed isn't really protecting anyone — it's just quietly generating failed login attempts, "forgot password" emails, and locked accounts. The people it hurts most are the ones already juggling the highest cognitive load: anyone with a memory or attention-related disability, anyone typing on a phone keyboard with fat-finger autocorrect, anyone using a password manager that didn't quite paste right. Today's quick win fixes it for all of them at once.
The Stat: WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum) (Level AA) names "remembering a password" as its own explicit example of a cognitive function test that must not be required without an alternative or assistance mechanism — a visible show/hide toggle is a documented way to help a user avoid transcription errors that lock them out. (Source: W3C)
Why a Masked Field Is Quietly a Cognitive Test
Think about what actually happens when someone fills in a password field. They type a string of characters they can't see, on a field that gives zero feedback about whether what landed matches what they intended. If it's wrong, they don't find out until the form rejects it — and even then, most login forms won't tell you which character was wrong, just that the whole thing failed.
That's a memory-and-verification task stacked on top of the login task itself. And WCAG 2.2's Accessible Authentication (Minimum) criterion treats that stack directly: it defines a "cognitive function test" as something like remembering a password or solving a puzzle, and it requires that authentication not depend on one of these unless there's an alternative method or some form of assistance available. Notably, the criterion's own documentation uses password memorization as its go-to example of the exact problem it's trying to solve.
A show/hide toggle is assistance. It doesn't remove the password requirement — it removes the blind-typing problem sitting on top of it. Suddenly a user can verify their own input before submitting, instead of finding out only after a failed attempt.
The Two-Part Fix
This is genuinely a two-attribute job, and both halves matter for different reasons.
1. A visible, labeled show/hide toggle
The toggle itself needs to actually work for assistive technology, not just sighted mouse users. That means:
- It's a real, focusable
<button>— not a clickable<span>or<div>with a click handler bolted on. - It has a text alternative that says what it does right now:
aria-label="Show password"when hidden, updated toaria-label="Hide password"once toggled — not a static icon-only button with no accessible name at all. - Toggling it doesn't move keyboard focus away from the password field, so someone can flip visibility mid-typing without losing their place.
- The visual state (eye icon open vs. crossed out, or the word "Show"/"Hide") changes in sync with the actual
typeattribute switching betweenpasswordandtext.
2. The right autocomplete value
This is the one-attribute part of the fix, and it's separate from the toggle but just as load-bearing. WCAG 1.3.5 Identify Input Purpose requires that common input fields expose their purpose programmatically, using standard HTML autocomplete values — so browsers, password managers, and assistive technology all know what a field is actually for.
For password fields specifically, that means:
autocomplete="current-password"on a login fieldautocomplete="new-password"on a signup or password-change field
Get this right and password managers autofill correctly, browsers stop guessing, and assistive technology can announce the field's purpose instead of just "edit text, password." Full details on accepted values and syntax are in MDN's documentation for the autocomplete attribute.
What "Done Right" Looks Like
| Field | Missing the fix | Fixed |
|---|---|---|
| Markup | <input type="password"> only |
<input type="password" autocomplete="current-password"> |
| Visibility | No way to verify input before submit | Adjacent <button> toggles type between password/text |
| Accessible name | Icon-only, no label, or a static label that never updates | aria-label updates to reflect current state ("Show"/"Hide password") |
| Password manager support | Browser guesses the field's purpose | autocomplete value tells it exactly |
| Focus behavior | Toggle click yanks focus away | Focus stays on the password field |
A Quick Checklist Before You Ship
- Show/hide toggle is a real
<button>, keyboard-focusable and operable with Enter/Space - Toggle has an
aria-labelthat updates with its current state, not a generic or missing name - Clicking the toggle doesn't move focus off the password field
- Login fields use
autocomplete="current-password" - Signup/change-password fields use
autocomplete="new-password" - No CAPTCHA-only or puzzle-only step gates the login with zero alternative method
The "But Isn't That Less Secure?" Question
This comes up every time a security-minded teammate hears "show the password on screen," so it's worth answering directly: a show/hide toggle doesn't weaken your authentication. It changes what's rendered in the browser's DOM for the person who is already sitting at that exact keyboard, looking at that exact screen, actively typing their own password into their own field. It does nothing to the value sent to your server, nothing to how it's hashed or stored, and nothing to what a remote attacker can see. The actual security-relevant question — is this password long enough, unique, and stored properly on the backend — is completely unaffected by whether the eight characters on screen render as dots or letters for the one person who already knows what they typed.
If there's a genuine shoulder-surfing concern (a shared kiosk, a public workstation), the fix is a policy about where that device is used, not making the field permanently unreadable for everyone including people who benefit most from being able to check their input. Framing the toggle as a security tradeoff usually just means the actual accessibility cost — locked-out users, failed logins, "forgot password" support tickets — never gets weighed against anything real.
One More Field to Check While You're In There
If your signup form asks for a password twice — the classic "Password" and "Confirm Password" pair — this is a good moment to reconsider whether you need it at all. The pattern exists to solve exactly the same masked-input problem a show/hide toggle already solves: catching a typo before submission. Once the toggle is in place, a second confirmation field is largely redundant, and it adds an extra field for every user to fill in, tab through, and get right, including in a masked state until they think to toggle both. Plenty of major products have already dropped the confirmation field in favor of a single password input with a working show/hide toggle — worth a look if you're doing a broader pass on this form anyway.
Small Fix, Real Payoff
None of this requires a redesign. It's one button and one attribute value, and together they take a page directly at what WCAG 3.3.8 is worried about: people getting locked out not because they don't know their password, but because they had no way to confirm they typed it correctly. Fix the toggle, fix the autocomplete value, and you've closed one of the most common — and most overlooked — authentication barriers on the web.
If you're not sure where your own login and signup forms stand, it's worth finding out before a user does it for you the hard way. Get a free scan that flags login and signup form barriers and see exactly what needs fixing.