A patient portal added input masks to its phone and insurance-ID text fields, and form completion dropped; what do masks break, and what would you specify instead?

## Three things teams call 'a mask' The word covers three designs with very different costs, and the diagnosis starts by knowing which one shipped. | Technique | What it does | Typical cost | |---|---|---| | **Restrictive input mask** | Forces each keystroke into a fixed template, inserts literals, blocks other characters | High: breaks paste, autofill, editing and non-standard values | | **Display formatting** | Leaves typing free, then groups the value for readability after the field is left | Low, if it never rejects what was typed | | **Format hint** | Shows an example in helper text; accepts any reasonable input | Near zero | A drop in completion after 'adding masks' almost always means the first kind. ## How restrictive masks fail real users - **Paste.** A patient copies a number from a letter or email that already has spaces or a country code. The mask rejects characters it did not expect, or keeps its own separators and the pasted ones, producing garbage. - **Autofill.** The device's saved phone number or address arrives in its stored format. A mask that reformats keystrokes can mangle a value inserted all at once. - **Caret and deletion.** Inserted literals move the caret unexpectedly, editing a digit in the middle can shift everything after it, and backspace can stall on a dash the person never typed. - **One format assumed.** A national phone template cannot hold an international number; an insurance ID template written for one insurer rejects another insurer's letters or length. The mask encodes a guess about the data as a hard rule. - **Screen readers.** The template's underscores, brackets and dashes may be read out as if they were the field's value, and each inserted literal can produce confusing echoes. - **It looks filled.** A box full of template characters can read as already answered. ## Diagnosing the drop 1. Find where people abandon or fail: which field, which error, which device class. 2. Reproduce the four classic paths: paste a formatted value, accept an autofill suggestion, edit a digit in the middle, enter an international or non-standard value. 3. Walk the field with a screen reader and with the platform's text-size setting enlarged. 4. Run a few usability sessions with the real population; for a hospital portal that includes older patients and carers entering someone else's details. In a hospital portal the cost is not only a lost form. A patient who cannot enter an insurance ID phones the front desk instead, and a phone number the mask reformatted wrongly means appointment reminders that never arrive. ## What to specify instead 1. **Accept liberally.** Allow digits, spaces, dashes, brackets and a leading plus in a phone field; allow letters where any real ID can hold them. 2. **Normalise silently.** Strip separators before validating and storing; never make the person do the machine's cleanup. 3. **Validate the normalised value**, and word errors about what is actually wrong: 'This number is too short' rather than 'Invalid format'. 4. **Show the format in helper text**, with a real example, so it stays visible while typing. 5. **Size the field to the expected length**, which quietly signals how much is wanted. 6. **Format for display only after the field is left**, and only if the formatted value is still accepted if edited or pasted back. The principle is old: be liberal in what you accept and strict in what you store. The strictness moves from the keyboard to the validator, where it can be precise. ## When a mask can earn its place Display grouping helps people check long digit strings, such as grouping a long number into blocks of four, because chunking aids reading. A restrictive mask is least harmful when the value is truly fixed-length, universally formatted, digits only, and rarely pasted. Even then, test paste, autofill and assistive technology before shipping, and treat 'masks are never allowed' as a strong default rather than a law. ## Across platforms Web and native mobile components both offer formatter hooks that can act as masks, and the failure modes are the same on each: the formatter runs on every change and fights the person. A cross-platform spec should describe the behaviour, accept, normalise, hint, validate, rather than name one platform's formatter.