Inputs that block paste, and why that fails users

What paste blocking is

Some forms cancel the paste event on password and confirmation fields, on the theory that retyping proves the user knows the value. It proves nothing, and it costs a lot.

Anyone transferring a password by copy and paste, from a manager, a note or another window, cannot enter it that way. A long generated password has to be transcribed by hand, which produces exactly the typos the field was trying to prevent. Users with a motor impairment, and users on a phone, lose the only practical way to enter a long string. The usual result is that people pick shorter, weaker passwords.

What squirrel checks

One check, paste-inputs, at severity warning. It covers <input> of type text, password, email, tel, url or search, <input> with no type at all, and <textarea>.

For each it reads the onpaste, oncopy and oncut attributes and flags any whose value contains, case-insensitively, return false, return!1, preventDefault, event.returnValue=false or event.returnValue=!1.

• Fail with N input(s) prevent paste. Items read password (blocks: paste, copy), naming the field by its name, falling back to id, then placeholder, then type. Every offender is listed.
• Pass with No paste-blocking inputs detected.
• Info with No text inputs found.

Only inline handler attributes are read. A listener attached with addEventListener is invisible here, so a pass is not proof that paste works. Test it by hand on the fields that matter.

How to fix it

<input type="password" name="password" autocomplete="new-password">

Delete the handler. There is no version of this that helps, and the standards bodies that used to recommend it have withdrawn the advice.

If the goal was to stop users pasting the wrong value into a confirmation field, drop the confirmation field instead and offer a show-password toggle. That catches real typos and leaves paste working.

Enable / disable

Disable this rule

[rules]
disable = ["a11y/paste-inputs"]

Disable all Accessibility rules

[rules]
disable = ["a11y/*"]

Enable only this rule

[rules]
enable = ["a11y/paste-inputs"]

enable replaces the default ["*"], so this is the only rule selected. Leave disable out: a rule that matches any disable pattern is skipped even when enable names it. Only an enabled setting under a rule’s own [rule_options] table overrides both lists.

Related rules

• a11y/autocomplete-tokens: autofill tokens on identifiable name, contact, address and payment fields.
• a11y/input-types: the other ways a form refuses help the browser offers.
• a11y/form-labels: whether those same password and text fields have an associated label.
• a11y/touch-targets: interactive elements with an inline dimension under 44 pixels.

Accessibility findings ship in every audit next to the SEO, performance and agent experience rules. See Website security scan with AI for how an agent works through a report.

References

• Element: paste event, MDN
• The autocomplete attribute, MDN
• Understanding SC 3.3.8 Accessible Authentication (Minimum), W3C

Check your site

Run squirrel audit https://example.com and open the Accessibility section of the report. Each field is listed with which of paste, copy and cut it blocks. Signed-out local audits need no account and cost nothing. Signed-in audits spend credits.