# Password fields that won't take a pasted password

Source: https://easeweb.dev/learn/password-paste
Topics: Page structure > Sign-in does not need a memory test (WCAG 3.3.8; EN 301 549 5.3)
The fix: Let the password go in the way people keep it. Either remove the handler that cancels paste and mark the form up so password managers can fill it, with autocomplete="username" and autocomplete="current-password", or, where the password step can't change, offer beside it a way in that needs no password, such as an emailed sign-in link.
Test with: keyboard, screen reader, password manager, autofill
References: https://www.w3.org/WAI/WCAG22/Understanding/accessible-authentication-minimum.html https://www.w3.org/WAI/WCAG22/Techniques/failures/F109 https://www.w3.org/WAI/WCAG22/Techniques/html/H100 https://www.w3.org/WAI/WCAG22/Techniques/general/G218 https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/autocomplete https://pages.nist.gov/800-63-4/sp800-63b.html https://www.troyhunt.com/the-cobra-effect-that-is-disabling/ https://www.chromium.org/developers/design-documents/create-amazing-password-forms/

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.

## What happens

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.

## Why it fails

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.

## Who is affected

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.

## What automation and AI miss

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.

## Before: a password field that cancels paste

```html
<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>
```

`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.

## After: a password field that takes a paste and can be filled in

```html
<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>
```

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.

## After: keep the password, and add a way in that needs none

```html
<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>
  <button type="submit" formaction="/sign-in/email-link">Email me a sign-in link instead</button>
</form>
```

The second button sends the form to another address, where the server emails a link that signs the person in, with nothing to remember or type but the email address. This is technique G218, and the alternative is enough to pass 3.3.8 even though the password field is unchanged. It is for a sign-in whose password step can't be changed, such as one run by a vendor. People who sign in with the password still can't paste it, and the link works only while they can reach their email and open the link before it expires.

## Which option to use

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.

## Implementation decisions

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](/learn/one-time-codes). 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](/learn/captcha).

## Verify the fix

1. Copy a saved password from a password manager app, or from a note, and paste it into the field with Ctrl + V or Command + V and with the context menu, and confirm the whole password goes in and signs you in.
2. Let the browser's own password manager offer the saved password, and confirm it fills both the email and the password.
3. Where there is another way in, such as an emailed link, use it from start to finish, and confirm it signs you in without the password.
4. With a screen reader, and with only a keyboard, sign in by each way the page offers, and confirm every field and button is reached and read with its label.

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.

---

Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)