Conveying in an accessible manner that input for a field is required is necessary only when there is a visual cue to this effect for the field. In other words, when there is no visual cue for required fields, WCAG 2 will not apply. The applicable Level-A success criteria are SC 1.3.1 and SC 3.3.2.
Consider the following four cases:
Case 1:
A text symbol (like an asterisk) or text indicating that input is required may be programmatically associated with the field using the label element (or legend for a group of related controls) or a title attribute (when no label is present) or the aria-labelledby attribute when it is relied upon to label the control.
If this is the case nothing extra is needed from a WCAG 2 compliance standpoint.
In these situations, using aria-required=true will:
– Help to reinforce the ‘required’ property when an asterisk or other text symbol is used … use of aria-required is optional and might be beneficial.
– Result in duplication, if the word ‘required’ is already associated with the control. So use of aria-required is discouraged.
Case 2:
A text symbol (like an asterisk) or text indicating that input is required is present but is not programmatically associated with the field.
In this situation, one could either programmatically associate the symbol or text with the field as part of the field’s label. This might be appropriate when the label text for the field too is not associated with the field.
Else one could use aria-required=true to indicate input is required in order to comply with WCAG 2.
Case 3:
The fact that input is required is conveyed by color only or font-style or a non-text symbol (including CSS).
In this situation, setting aria-required=true will certainly help some users who depend on ARIA-enabled user agents-assistive technology.
Simply relying on color alone or visual styling to indicate required property will not help users who cannot distinguish color / styling differences due to a visual impairment and do not routinely need any assistive technology.
In fact, using color or styling differences alone to indicate required fields should be a failure of WCAG 2, just like it is a failure to use CSS images for essential content (Technique F3).
Case 4:
Sometimes there’s a note preceding (or following) a form that all fields are required unless marked as optional. This may be an efficient way of indicating required fields when only a minority of fields is optional. The text ‘optional’ is programmatically tied with the fields for which input is not mandatory.
In this situation, using aria-required=true is not required for WCAG 2 compliance. If it is used, some users might consider it helpful and some might disagree. It depends on the context.
If the word “optional” is not associated with the fields that are not required, the fix is either to make the association or to use aria-required=true on the fields that do require input.
Conclusion:
Hopefully the above will help content authors determine when it is easier to use technique H90 (Using label/ legend element to indicate required fields) or aria-required=true in order to comply with WCAG 2.
Admittedly, when required fields are clearly indicated it will minimize input validation errors. But that is a matter of functionality and usability to be considered by the content author. Also, complying with SC 3.3.1 Level A (Error indication) and SC 3.3.3 Level AA (Error Suggestion) will be less onerous if there are fewer input violations. But these SC are not concerned with proper indication for required fields.
References:
- Web Content Accessibility Guidelines
- H90: Indicating required form controls using label or legend
- ARIA2: Identifying required fields with the aria-required property
- F3: Failure of Success Criterion 1.1.1 due to using CSS to include images that convey important information
Sailesh Panchang is the Principal Accessibility Consultant at Deque Systems