# Password inputs must not block password managers. Avoid autocomplete="off" and allow pasting.

> Canonical HTML version: https://rocketvalidator.com/accessibility-validation/accesslint/0.16/input-assistance/accessible-authentication
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

Password fields that block password managers create barriers for people who rely on stored credentials to log in. Two common patterns cause this: setting `autocomplete="off"` on a password input, and attaching an `onpaste` event handler that prevents pasting. Both patterns force users to manually type their passwords, which is a problem for several groups of people.

Users with cognitive disabilities may not be able to memorize complex passwords. Users with motor impairments may find it difficult or painful to type long strings of characters. Users with memory difficulties may depend entirely on a password manager to handle authentication. When a site blocks these tools, those users can be locked out or forced to use weaker passwords they can remember.

## How this relates to WCAG

WCAG 2.2 Success Criterion 3.3.8 (Accessible Authentication — Minimum) at Level AA requires that authentication steps do not rely on cognitive function tests unless the site provides an alternative mechanism that assists the user. Typing a memorized password is a cognitive function test. Password managers are one such assistive mechanism: they fill in credentials automatically or let users copy and paste stored passwords. When a password field blocks either of these workflows, the site removes the mechanism that would otherwise satisfy the success criterion.

## How to fix it

There are two things to check on every password input:

1. Set the `autocomplete` attribute to an appropriate value. For login forms, use `autocomplete="current-password"`. For registration or change-password forms, use `autocomplete="new-password"`. Never use `autocomplete="off"` on password fields.

2. Do not attach `onpaste` handlers that call `preventDefault()` or return `false`. If a paste handler exists for other reasons (such as logging), make sure it does not actually block the paste operation.

These are mechanical fixes. In most cases, removing `autocomplete="off"` and any paste-blocking code is all that is needed.

## Examples

### Incorrect: `autocomplete="off"` on a password field

```html
<label for="pw">Password</label>
<input type="password" id="pw" autocomplete="off">
```

This tells browsers and password managers not to offer stored credentials for this field.

### Incorrect: paste blocked with `onpaste`

```html
<label for="pw">Password</label>
<input type="password" id="pw" autocomplete="current-password" onpaste="return false;">
```

Even though `autocomplete` is set correctly here, the `onpaste` handler prevents users from pasting a password copied from a password manager.

### Incorrect: both problems at once

```html
<label for="pw">Password</label>
<input
  type="password"
  id="pw"
  autocomplete="off"
  onpaste="event.preventDefault();">
```

### Correct: login form

```html
<label for="pw">Password</label>
<input type="password" id="pw" autocomplete="current-password">
```

The `autocomplete="current-password"` value tells the browser this is a login field. Password managers can fill it, and paste is not blocked.

### Correct: registration or change-password form

```html
<label for="new-pw">New password</label>
<input type="password" id="new-pw" autocomplete="new-password">
```

Using `autocomplete="new-password"` signals that this field expects a new credential. Password managers can offer to generate and save a password here.