Input masks that change a typed or pasted number

A shop's checkout asks for a phone number, so the courier can text when a parcel is on its way. The field is drawn with the format inside it, (__) -, so people can see what to type, and as they type, the digits fill the blanks. The developer builds it with one line of a popular mask library, or with a few lines of their own that add the brackets and the dash as each digit goes in.

A customer copies their number from their contacts, where it is saved as +1 212 555 0147, and pastes it. The field shows (121) 255-5014. It looks like a phone number, so they press Continue, and the texts go to someone else. The mask has ten places, and it fills them with the first ten digits it is given: the country code 1 becomes the start of the area code, and the last 7 is dropped. Typing +1 first does the same: the + is thrown away without a word, and the 1 takes the first place. We tried the mask in Chromium with Inputmask 5.0, IMask 7.6, Maska 3.2 and the hand-written version below, in October 2026, and each turned the pasted number into (121) 255-5014. IMask's tracker has the same kind of report for its +7 mask: a number pasted with a leading 8 comes out wrong.

The two ways it gets built fail in two more ways:

• With the library, the pattern is the field's value as soon as it takes focus. A screen reader reads the brackets and blanks as what the field holds; an Inputmask user reported it read out as "underline underline underline…".
• With the hand-written version, every change rebuilds the value, and the caret jumps to the end. Someone who notices a wrong fourth digit, deletes it and types the right one finds it added last: (212) 550-1479.

No success criterion fails here, and this guide is a best practice. Success Criterion 3.3.2 Labels or Instructions asks for labels or instructions where content needs input, and its Understanding document says they may give the expected format (technique G89, the format with an example). Both Befores pass it: the field has a label, and the library's pattern even shows the format. Nothing in WCAG asks a field to take a number in more than one form.

The advice comes from design systems and testing. GOV.UK's telephone number pattern says to avoid input masking, because it makes it harder for people to type a number the way they prefer and to copy one out from somewhere else and check it, and to allow spaces, hyphens, dashes and brackets, and country and area codes. Filament Group found the blanks were "little more than aural garbage" read aloud on focus, and that a script rewriting the value as people type makes screen readers read out fragments of it.

The failure is in how a mask reads what it is given. It knows one format with a fixed number of places, reads each character in turn, drops any its format doesn't take, such as the + and the spaces, and puts each digit in the next place until the places run out. A number written another way doesn't fit, and nothing tells the person what was dropped. The caret is the browser's doing: when a script sets an input's value, HTML moves the caret to the end of the text, so a handler that rebuilds the value on every change takes the caret away from where it was.

One part comes close to a criterion. Success Criterion 3.3.1 Error Identification asks that an input error the page detects is described in text, and its Understanding document says that when a value is too high or too low and the page's code changes it by itself to fall within the allowed range, the error still has to be described. A mask that throws away the + and a digit without a word is near that case. The fixes below throw nothing away, so the question doesn't come up.

Anyone who doesn't type the number digit by digit in the mask's own form meets this: people who paste it, people whose browser fills it in, and people who write it as it is printed on their card. A number saved in a contacts app, or filled in by the browser, can come with its country code in front, so the paste is not an odd case.

4 of 10 groups affected

• No vision (affected)
• Low vision (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)

• Without vision While the field has focus and nothing is typed, its value is the pattern (__) -, so a screen reader reads brackets and blanks as what the field holds. As digits go in, it reads a mix of digits and blanks back, and a pasted number that changed into another one is never announced.
• Limited manipulation People who type with a switch, a mouth stick or one finger copy a number, or let the browser fill it in, to save presses. The mask turns a number with +1 in front into a different one, and correcting it in a field that sends the caret to the end costs many more presses.
• Limited language, cognitive and learning abilities Checking a number against the one it was copied from is hard when the field shows it in another shape, and harder still when the digits have changed: (121) 255-5014 still looks like a phone number, so nothing says it is wrong.
• Limited vision Under magnification only part of the field may be in view. When the caret jumps to the end after a correction, the next digit goes in at the end, away from the digit they were looking at.

The field has a label, the page passes axe, and a scan never pastes anything. EaseWeb's audit pastes +1 212 555 0147 into each phone field, and 4242 4242 4242 4242 into each card number field, by script, then puts the value back without sending the form. It lists a field whose digits come out different, and a field whose value is a pattern of blanks, for a person to try. These are leads, not findings, since no criterion fails. Where the caret goes, and what a screen reader reads as each digit goes in, need a person. A code assistant asked for "a phone field formatted as (999) 999-9999" can write either Before.