Search topics
Password fields that won't take a pasted password
An energy supplier's sign-in cancels paste on its password field, so a password copied from a password manager can't go in and has to be typed from memory.
<input type="password" onpaste="return false"> The problem
People who keep their password in a password manager, or can't remember it exactly, can't paste it in, so they have to recall it or copy it out character by character.
An energy supplier's account page asks for an email address and a password. Someone who keeps their passwords in a password manager app opens it, copies the long random password it made for them, and pastes it into the password field. Nothing goes in. The field cancels paste, a rule someone added years ago to stop passwords being pasted from somewhere unsafe. The password manager in the browser may still fill the field, because filling in isn't pasting; but a password manager on another device, one that can't fill this browser, and the note where they wrote it down all work by copy and paste. What is left is to read the password from one window and type it into the other, character by character, into a field that shows only dots.
The same step fails in other ways:
- A field with
maxlength="12"cuts a pasted or filled password of twenty characters to its first twelve, and the sign-in says the password is wrong. - A bank asks for the 2nd, 6th and last characters of a memorable word, each from a menu, which no password manager can fill, and which means counting the word out from memory.
- The page offers only a fingerprint or a face scan, with no password or other way in at all. 3.3.8 doesn't count that as a test, but it shuts out people who can't use one, and EN 301 549 clause 5.3 rules it out.
Success criterion 3.3.8, Accessible Authentication (Minimum), is level AA and new in WCAG 2.2. No step of signing in may need a cognitive function test, such as remembering or transcribing a password, unless the step offers another way in that needs none, or a mechanism that helps people pass it. (Its two other exceptions, recognising objects and recognising content the person gave the site, don't apply to a password.) A note to the criterion gives two examples of such a mechanism: password managers, which hold the password so people don't have to, and copy and paste. The Understanding document says plainly that blocking paste into a sign-in field fails, because it leaves transcription as the only way in.
Failure F109 describes the same thing from the other side: a password must be able to go in whole, in the format it was created in. A field that refuses a paste, cuts a password short, or asks for some of its characters in separate fields fails, unless the same sign-in offers another way that needs no transcription. The browser lets a page cancel any paste with one handler, and shows no sign that it did: the field just stays empty.
The fault falls on exactly the people who did what security advice tells them to: use a different long password for every site, kept in a password manager rather than in their head.
3 of 10 groups affected
- No vision (affected)
- Low vision (not affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities People with memory difficulties, dyslexia or dyscalculia rely on a password manager to hold a long password they could never recall. With paste blocked, they have to read it out of the manager and type it back, character by character, and one swapped character means starting again.
- Limited manipulation Someone using a switch, an on-screen keyboard or voice input picks out every character of the password one at a time, where a paste would have taken one action. A strong password of twenty random characters can take minutes, and a slip is easy.
- Without vision A screen reader user can't see what they type into a password field, only hear it read as dots or stars, so copying a long password by hand means listening to it in the manager, character by character, and typing it blind.
The fields have labels, so axe and other scanners pass the form; none of their rules tries a paste. EaseWeb's audit pastes a single character into each password field that is the only one in its form and isn't for a new password, and reports any field that cancels the paste and puts nothing in; it never submits the form. It can't tell whether a password manager can fill the form, or whether another way in, such as an emailed link, works from start to finish: a person has to try both. A code assistant asked to make a sign-in "more secure" can add a paste blocker to the password field, and one asked for a login form can leave out the autocomplete attributes that tell a password manager what each field is.
Try it
Choose Copy password in the password manager, then paste it into the Password field with Ctrl+V or the context menu.
The panel under the page shows how much of the password went in. If copying is blocked here, select the dots in the manager and copy them yourself.
Broken Can you fix this?
What went in: 0 of 21 characters
The fix
Let the password be pasted or filled in, or offer a way in that needs no password.
- 1Never cancel paste or drop on a sign-in field.
- 2Mark the username and password up so password managers can fill them.
- 3Where the password step can't change, offer a way in that needs no password.
<form action="/sign-in" method="post"> <label for="email">Email</label> <input id="email" name="email" type="email"> <label for="password">Password</label> <input id="password" name="password" type="password" onpaste="return false"> <button type="submit">Sign in</button></form>A password field that takes a paste and can be filled in
<form action="/sign-in" method="post"> <label for="email">Email</label> <input id="email" name="email" type="email" autocomplete="username"> <label for="password">Password</label> <input id="password" name="password" type="password" autocomplete="current-password"> <button type="submit">Sign in</button></form>onpaste="return false" cancels every paste into the field, with the keyboard, the context menu or a password manager app, and the field gives no sign that anything was refused. The only way left to enter the password is to remember it or copy it out by hand.
With the paste handler gone, a password goes in the way any text does: pasted, dragged in or filled in. This is technique H100: the email and password are real inputs in one form, each with a label, and autocomplete="username" and autocomplete="current-password" tell the browser and password managers what each field holds, so they can offer to fill both and to save a new password. No script is needed.
Both pass 3.3.8. Let the password be pasted and filled in: it fixes the step everyone uses, with less code, and the emailed link leaves the password step as hard as it was. Add the emailed link, or a passkey, as well where you can: it helps the people who can't manage a password at all. Keep the paste blocker only when you can't change the field, and then make sure the other way in is as easy to find as the password.
Blocking paste doesn't make a password safer. The reasons sites have given for it, collected by the security researcher Troy Hunt, don't hold up.
- To stop programs that try password after password. Such a program fills in the field or sends the form straight to the server, and never needs to paste, so the block stops only people.
- To keep the password away from malware that reads the clipboard. Malware on the device can just as well record the keys as the password is typed.
- So that a password longer than the site's limit isn't cut short without anyone noticing when it is pasted. The fix for that is to lift the limit, or to state it beside the field.
What the block does do is push people towards passwords short enough to type, and a password manager's long random password is far stronger than any of those. The US National Institute of Standards and Technology's digital identity guidelines say services shall allow password managers and autofill, and should let people paste a password.
A "Show password" button that switches the field to type="text" and back helps people check what they typed, and the Understanding document suggests one. Make it a real button with aria-pressed, so a screen reader says whether the password is showing.
Don't set autocomplete="off" on a sign-in field: it asks the browser not to offer what it has saved, though most browsers ignore it on login fields. Don't split one form into separate pages for the email and the password without a hidden username field on the second, or password managers may not know what to fill.
A passkey, signed in with the device's own fingerprint, face or PIN, is another way in that passes 3.3.8, because the Understanding document doesn't count a device's own sign-in, such as Windows Hello or Face ID, as a cognitive function test. Offer it beside the password, not instead of every other way: a fingerprint or face as the only way in shuts out people who can't use one, and EN 301 549 clause 5.3 asks that no single biological characteristic be the only way to identify a user.
Codes sent by text message or email are the same kind of step, and need the same paste test; see one-time code boxes that won't take a pasted code. A puzzle to solve before signing in, such as distorted letters, falls under the same criterion; see CAPTCHAs with no way past them except solving the puzzle.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Screen reader, Password manager, Autofill
Record the OS, browser, password manager and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the sign-in form or the component library it is built with changes.
Limits
This is a starting pattern, not a guarantee for every sign-in. It covers the password step; every other step of signing in, such as a code, a security question or a puzzle, needs the same test. The criterion covers signing in to an account that exists, not creating one, though setting a password should take a paste for the same reasons. Whether an emailed link reaches people in time depends on their email, which the page can't test. Test the whole sign-in with the password managers and tools your users rely on.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: accessible-authentication-minimum (opens in a new tab)
- WCAG Technique F109 (opens in a new tab)
- WCAG Technique H100 (opens in a new tab)
- WCAG Technique G218 (opens in a new tab)
- developer.mozilla.org: autocomplete (opens in a new tab)
- pages.nist.gov: sp800-63b (opens in a new tab)
- troyhunt.com: the-cobra-effect-that-is-disabling (opens in a new tab)
- chromium.org: create-amazing-password-forms (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.