Web forms frequently ask for a single piece of information that is broken up into multiple input fields. The most common examples of this are dates, phone numbers, and Social Security numbers. The problem with these is that the way they are frequently implemented can cause difficulties for people with certain disabilities, and they also don’t technically meet accessibility standards. Here is how they are frequently implemented.
Here are the problems with this technique.
- “Select a date” is a label (although many times it isn’t even made into a label) but it is not attached to a form element. That is understandable because which form element would you attach it to. You are only allowed to associate a label with one input element, so it usually does not get associated at all.
- When the user goes to each of the “Month”, “Day”, and “Year” input elements, since there is no explicit label the user must guess from the context what is being asked for. I daresay most screen reader users have probably become quite adept at this skill out of necessity. Additionally, screen readers applications now attempt, with varying degrees of success, to discern a relationship between two elements when none is explicitly defined. Screen reader users will usually hear something like the following when trying to enter information.
- When entering the month, “Select a date. Combo box. Jan. To change the selection use the arrow keys.” (It’s possible they won’t even hear “Select a date”)
- When entering the day, “Combo box. 1. To change the selection use the arrow keys.”
- When entering the year, “Combo box. 1990. To change the selection use the arrow keys.”
We can make a much more accessible implementation of this using the aria-labelledby attribute in place of explicitly tying a form label to an element with the “for” and “id” attributes. The aria-labelledby attribute lets us attach multiple labels to a single input element. In the following code each input element is linked to two different text elements by the aria-labelledby attribute.
<p> <span id="selectDate">Select a date</span> <span id="monthLabel">Month</span> <select name="month" id="month" aria-labelledby="selectDate monthLabel"> <option value="Jan">January</option> <option value="Feb">February</option> <option value="Mar">March</option> ... </select <span id="dayLabel">Day</span> <select name="day" id="day" aria-labelledby="selectDate dayLabel"> <option value="1">1</option> <option value="2">2</option> <option value="3">3</option> ... </select> <span id="yearLabel">Year</span> <select name="year" id="year" aria-labelledby="selectDate yearLabel"> <option value="1990">1990</option> <option value="1991">1991</option> <option value="1992">1992</option> ... </select> </p>
In this case a screen reader will read something similar to the following:
- When entering the month, “Select a date. Month. Combo box. January. To change the selection use the arrow keys.”
- When entering the day, “Select a date. Day. Combo box. 1. To change the selection use the arrow keys.”
- When entering the year, “Select a date. Year. Combo box. 1990. To change the selection use the arrow keys.”
Here are two working example of this technique with some CSS styling. This blog cannot properly display input elements with aria-labelledby attributes within the post, so the examples must be viewed from a different site.
If you implement your form in this way you may run into an issue. Some accessibility checkers will say it’s invalid because you are not explicitly tying a <label> to an <input> element. In my opinion this is a perfectly valid way to present a form and the accessibility checkers need to update their criteria. This is an example of where machine validation doesn’t rule the day.