Have you ever filled out a form, clicked submit, and gotten an error saying some required fields were left blank? That can be frustrating, especially if the required fields were not clearly marked.
Digital forms serve many purposes, from capturing customer support questions to submitting job applications and everything in between. It’s essential to designate certain form fields as “required” to ensure that users can successfully submit the form. However, this step is often overlooked.
That can cause problems for site visitors, as most forms have both required and optional fields. If a form does not properly differentiate between these field types, it can also create an accessibility issue.
You can avoid this issue by clearly communicating which fields are required before users click submit, while they are still in the midst of filling out the form.
Exploring your options
For some forms, all fields are required. In this case, you can preface the form with a note stating, “All fields required.”
In the more common case that a form has a mixture of required and optional fields, there are several conventions you can use to designate which fields are required. These conventions differ in accessibility level, with some being inaccessible and others being highly accessible.
An inaccessible example would be using different colored labels to differentiate between required and optional fields. By just using colors, you are alienating colorblind, visually impaired, and blind users who cannot distinguish between the different colors.
Another common approach is to add an asterisk or icon to the label for required fields. While some screen readers will pick this up, others will not. For an icon to be read to the user, it really depends on how the icon is inserted and whether it has alt text. An asterisk will usually be read if it’s part of the <label> element (or <legend> in the case of a radio group).
While some may argue that an asterisk alone will suffice, many site creators want to communicate a field’s required status more clearly.
A tale of two properties
The aria-required=”true” attribute is specifically designed for this purpose. Inserting this ARIA attribute into your form field code is supposed to trigger screen readers and other assistive technology to recognize the field’s required status and communicate it to the user. For example:
<label for="fname">First name</label>
<input type="text" id="fname" name="fname" aria-required="true">Another, newer option is the HTML 5 required property. It can be added to form fields just like aria-required=”true” and it’s supposed to alert screen reader users that the field is required.
<label for="fname">First name</label>
<input type="text" id="fname" name="fname" required>However, where HTML 5 required differs from aria-required=”true” is that HTML 5 required actually has behavior associated with it. It’s not intended only to communicate information, but also to prevent the browser from accepting a form when one of its required fields is empty.
Unfortunately, there is a lack of consistency in how browsers treat the HTML 5 required property, making it unpredictable and, therefore, unreliable.
Troubles ahead
As with far too many accessibility solutions, there is the way that things should work, and then there’s the way they actually work.
ARIA has always been a supplement to fill gaps in the semantics of a native language like HTML. Once the native language introduces a feature to perform that function, the use of ARIA should be discontinued. Following this logic, now that HTML 5 required is here, we should theoretically discontinue using aria-required=”true”.
The HTML 5 required property should be — and possibly will be in the future — the best solution. Unfortunately, the reality as of this writing (08/2020) is that support among browsers and screen readers for HTML 5 required remains spotty and highly inconsistent.
Just as unfortunately is that support among browsers and screen readers for aria-required=”true” is also far from perfect.
So, what should you do?
To hack or not to hack
While there may not be a perfect solution that works in all circumstances, there is a simple solution that works with most forms so long as the form fields have associated <label> (or <legend>) elements.
This solution is to append a note to the <label> or <legend> indicating that the field is required and dispense with the HTML and ARIA properties altogether. For example:
<label for="fname">First name (required)</label>
<input type="text" id="fname" name="fname" required>Although it might seem like a hack to some, it’s simple and robust and will be read by more browser and screen reader combinations than either HTML 5 required or aria-required=”true”, especially with less common form field types where support is lacking the most.
If it seems cluttered to have the required notification appended to <label> and <legend> elements, it’s even possible to visually hide them while still having them read by screen readers. If a “screen reader only” CSS style is applied to the appended notification, it won’t appear on screen but will be read to assistive technology.
One example of a screen reader only CSS class:
.sr-only
{
border:0;
padding: 0;
clip: rect(1px, 1px, 1px, 1px);
clip-path: inset(50%);
height: 1px;
margin: -1px;
width: 1px;
overflow: hidden;
position: absolute !important;
word-wrap:normal !important;
}Applying the CSS class to the HTML:
<label for="fname">First name<span class="sr-only"> (required)</span></label>
<input type="text" id="fname" name="fname" required>One weakness of this approach is that the HTML 5 required property is sometimes needed for validation. Without it, users would be able to submit a form even with required fields left blank. However, these days, form validation is more often handled by frameworks or content management systems. Thus, validation of required fields — as well as other validation measures such as correct formatting of data — functions robustly whether the HTML 5 required property is used or not.
As mentioned earlier, the HTML 5 required property might turn out to be the ultimate solution someday. But for site creators working, it simply lacks the support to be reliable.
