Aria-required=true: WCAG 2 Compliance versus Best Practice

Wheel chair with arrows pointing forward on a blue backgroundBecause the attribute “aria-required” is supported by commonly used browser-assistive technology combinations, many consider its use as the easiest and most optimal method for indicating that input is required for a field. Yet, recommending its use may not be so straightforward from a strict WCAG 2 compliance viewpoint.

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:

Sailesh Panchang is the Principal Accessibility Consultant at Deque Systems

 

Photo of Sailesh Panchang

About Sailesh Panchang

One of Deque’s first employees, Sailesh is experienced in conducting accessibility assessments of Web content and software using combination of automated and manual-testing techniques including code reviews. In addition, he works to enable Deque clients to get started and become effective users of Deque’s tools.

Sailesh is very strong in application of accessibility techniques for HTML and WAI-ARIA for complying with Section 508, WCAG and legislation like Air Carrier Access Act (ACAA). Sailesh is an assistive technology user and relies on screen reading software like JAWS, NVDA, VoiceOver and TalkBack.
update selasa

Comments 2 responses

  1. Hey Sailesh, Great Post! I just want to remind readers that the NVDA screen reader for Windows ignores * (asterisk) at the default settings. Most users don’t change their default screen reader settings so if you use only an asterisk * in the label or accessible name of the form control NVDA users will not hear that “star” spoken unless they do letter by letter navigation. NVDA will, however, always read the aria-required and aria-invalid attributes at default settings.

    So while it may not be a requirement for WCAG compliance to use required, aria-required, or aria-invalid attributes, I do highly recommend it from my experience.

    Thanks!

  2. So based on the sentence in the artiucle, saying

    “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.”

    is it correct to state that this is only relevant for non-sighted users?

    Olaf

    PS: Does this page become invalid once it includes my comment with text for a quote in it without the quote being tagged as a quote? Do I have to use HTML to assign this tag?

Comments are closed.