Multiple form inputs for one piece of data: bad news for accessibility

During lived user accessibility testing, one pattern I've repeatedly found to be a problem for blind users is multiple inputs for one piece of data.

For example:

• A Canadian postal code with separate inputs for each character
• A driver's license number with three inputs, one for each set of five characters
• A credit card date with separate inputs for month and year

Why is this done? Typically, it's to ensure the data is entered in the correct format and reduce errors. But it creates new problems for blind users.

The typical issue is that the blind user focuses the first input in the set, assumes that it's the only one, and tries to enter all the data in this field. Typically, it will have a character limit, but they may not realize when they've hit the limit, and keep typing even though nothing is being entered.

When they navigate forward, they may or may not realize what has happened, depending on the form messaging and the ability of the user.

Sometimes this issue is "solved" by automatically advancing the user's focus to the next input as they type. For example, the postal code with six individual inputs did this. This works when the user initially enters the data, but the problem comes when they go back to check their input. My testers found it confusing and difficult to have to navigate back through six different inputs to check what they'd typed. Normally a blind user will navigate character by character through their input in a form field when they want to check it, but this pattern means they can't.

How to fix this issue

Option 1: Use only one input, with good messaging

One way to remediate this issue is very simple; just use one input but ensure you have very good labelling and instructions to guide the user as to the correct input format.

A very frequent cause of problems for both disabled and non-disabled users is poor form labelling and messaging. Many issues could be reduced or eliminated altogether by following accessible form practices:

• Every input must have a visible label which accurately describes the input purpose, provided using the actual HTML <label> element
• This label must be programmatically associated with the input using the <for> attribute on the label. The value of the <for> attribute is the unique ID of the input. This is so blind users hear the label when they enter the field, for example "First name, edit".
• Where the field requires a specific input format, for example a credit card date, it has clear instructions as to the format.
  • These instructions can be provided in the label, e.g. "Credit card date (format: 03/25)"
  • Or, they can be provided as help text either between the label and the input or just after the input. If this is done, the text must also be programmatically associated with the input, again so blind users hear it when their focus enters the field. This is done by putting a unique ID on the help text, putting aria-describedby on the input, and giving aria-describedby the help text ID as its value.
• For standard types of data, like postal code and credit card date, use the correct autocomplete value so it can be autofilled with the user's saved browser data, if any. This greatly helps users to complete forms quickly, easily, and with fewer errors.

This isn't an exhaustive list of considerations for accessible form inputs of course, just a shortlist of ones which can help users understand and enter the correct data in the correct format.

Option 2: format the inputs as a grouping, also with adequate labelling and instructions

A second option for accessibly programming a group of inputs for one piece of data, is putting them together in a <fieldset>.

Please note I've only tested a form which included this pattern once, and it confused users just as much. I think this was largely due to poor labelling and messaging, so it possibly could work if that's done well, but I don't recommend this pattern, at least without further testing. This is just how I'd do it if for some reason I was forced to.

• Put the multiple inputs into one <fieldset>. This will cause screen readers to announce them as a "group" or similar, e.g. "Driver's license number, group", and alert the user that there is more than one input here.
• Ensure the fieldset has a <legend>, and ensure the legend accurately describes the inputs as a group. E.g. the driver's license legend would probably be "Drivers license number".
• As above, ensure that each field has a programmatically associated, visible label which accurately describes its purpose. One of the issues with the driver's license inputs in our testing was that the audible label of the first input was "Driver's license number", not "First five characters of driver's license number."
• As above, also ensure that each field has programmatically associated, visible help text which describes the correct input format.
• Do not be tempted to visually hide any of the input labels or help text. It is not only blind users who need help with input format, although this is a common misconception and developers end up littering their creations with invisible text which just ends up being extra, unnecessary noise in the screen reader, or actually useful text which sighted users miss out on.

Those are my suggestions as of now. I'll update this post in the future as needed with any new findings.