Introduction - What is input masking
An input mask is an input field that automatically formats as you type in a value. The input field uses the native HTML5 “pattern,” which takes in a regular expression to determine if the formatting is correct.
Many benefits can come from input masking, but if done wrong, it can lead to many usability and accessibility challenges.
Please note – that these are my opinions on what makes an accessible input mask. I could not find much helpful information online in 2023, so I’m writing my guidance. Please let me know if you have any issues, concerns, or ideas to improve this resource.
If input masking is done well, for many, it can be a good user experience that we don’t even notice. For example, some of the benefits users can have is:
- Speed: Saving users time by automatically helping them get the correct format.
- Prevention for error: Users are less likely to misformat a telephone number, reducing friction in a shopping experience.
- Consistency in data: When you’re taking in customer data, you want that data to be structured.
- Easier to read: The input mask can make the input field visually more appealing and organized when applied to the format.
- Reduced anxiety: It can help increase confidence by teaching users how we should be entering data.
Challenges of input masking:
When input masking goes wrong, it can cause many usability and accessibility challenges.
- Confusing for screen reader: When items inject on the screen without warning a screen reader user, it can be a confusing experience.
- Difficulties fixing typos: When a user makes a mistake in their values, often fixing those errors can be complex when masking is applied.
- Sometimes complex: Input masks can also make it more difficult for users to enter data, especially if the mask is complex or the user is not familiar with the format.
- Less flexible: Users have preferences. Input masks may limit input flexibility, preventing someone from entering data in a way that feels most comfortable to them.
1. Always use the best input type for the job.
The correct input field type will allow users on a mobile device to see the proper keyboard. The UK government design system researched this and recommended using an input to the kind of “text” and the input mode of “numeric.”
Below you will find a code snippit. You can skip this code-snippet by navigating to the next heading level 3.
2. Don’t allow users to enter symbols
Do not let users insert symbols such as slashes, dashes, or spaces. Make the job simple by only allowing users to enter digits (numbers only).
3. Allow users to edit anywhere
We must let a user edit anywhere they like, whether at the beginning or in the middle of the input field. If a user deletes a character, don’t automatically move focus to the end of the input field; Keep the focus in the same location. For example, many input fields force users to begin typing at the end of the input field when they make a mistake. When functionality is removed from the native default, it can be extremely frustrating.
We need both visible helper and off-screen helper text. When I mention helper text, I’m referring to information that gets placed in the accessible description of an element.
- Visible Helper:
- If there are number constraints, describe the digit count and the field name in the visible helper text. Such as a “10-digit phone number” or “16-digit credit card number.”
- Off-Screen Helper Text:
- The off-screen helper text must let the screen reader user know that the form field has an input mask. Such as: “This field has masking. It will automatically format as you type.”
- The off-screen helper text must let the user know which inputs are allowed. Such as: “Only numbers are allowed.”
5. Both form constraints and patterns should be visible on the screen and programmatically associated.
- Form constraints: must always be visible, especially if it’s a field you can misinterpret. For example, the date field can have formatting such as “MM/DD” or “DD/MM.” Instructions on the constraint should be visible to let a user know what we need. Place the date formatting in the label, as it’s usually the most contrasting element and is usually more noticeable.
- Placeholder Patterns: Must always be visible to let sighted users know how many characters need to be typed and set to aria-hidden. Developers should not place the placeholder pattern in the “value” property of the input field; Otherwise, it can cause confusing announcements for the screen reader. Placeholder patterns typically use underscores to explain the design, such as “(___)-___-____”. Youtube Video: placing underscores as the value – bad example.
6. Allow users to copy/paste values.
Supporting pasting also means allowing users to use the browser’s autocomplete or a tool such as a password manager to paste values. The goal is to add functionality with the input masking and not to remove it. Removing copy/pasting from an input field goes against the browser’s default which can be confusing, so it needs to be supported.
Should the MM/DD/YYYY be uppercase or lowercase?
After conducting a test, I found that the constraint/pattern should be set to uppercase. However, we should also rely on the helper text (requirement 4) to inform users as it’s the most consistent.
|Screen Reader Name||Uppercase or Lowercase||Notes|
|MacOS VoiceOver (Desktop)||Uppercase||Uppercase is preffered in MacOS desktop. Voiceover announces "YYYY" much better. If it's lowercase, it says "EE-Eye"|
|iOS VoiceOver (Mobile)||Neither||Neither/ Voiceover on iOS mobile + safari, they announced only two letter "y" regardless of the case used. The preffered solution is to rely on helper text described in requirement #4.|
|Jaws||Uppercase||Uppercase is preffered in Jaws. Jaws announced up to 3 letter "y" when capitalized. When it was lowercase it only announced "EE-Eye."|
|NVDA||Both||NVDA announced them both correctly in full. We heard 4 letter "y" announced.|
Visit the following to see a code demo: Codepen: Accessible Form Input Masking – Giovani Camara
In the code demo, I used the input masking library by Estelle. Youtube: Watch a video of me using this feature with VoiceOver
Below is an iframe of a codepen code example. Skip by heading 2 to navigate past this, you will encounter the conclusion heading.
This blog post would not be complete if I didn’t list the alternatives. You could also opt out of using input masking and relaying on separate input fields. For example, the UK Gov Design System uses separate input fields to make this pattern accessible. You could argue it’s slower because you add more tab stops, or it takes up more space. It’s really up to preference.
In conclusion, form masking can be an excellent toolset for your website if you follow these tips to make it accessible.
As always, if you find anything in this article that can be improved, is incorrect, or anything at all, please let me know.
Find me on Linkedin: Giovani Camara
- Article: Why the GOV.UK Design System team changed the input type for numbers
- Github: Accessible input masking by Estelle
Related WCAG Requirements
- SC 4.1.2: Name, Role, Value (Level A)
- Relates to: Requirements 1.
- SC 1.3.1: Info and Relationships (Level A)
- Relates to: Requirements 1 and 2.
- SC 3.2.2: On Input (Level A)
- Relates to: Requirement 3.
- SC 3.3.2: Labels or Instructions (Level A)
- Relates to: Requirements 4 and 5.
- SC 1.3.5: Identify Input Purpose (Level AA)
- Relates to: Requirement 6.
- 01/19/2023: Made grammar and typo updates. Thanks to Diane Ko for the recommendations.
- 1/20/2023: Added an alternative to input masking and a video explaining requirement #5.