Using Aria-invalid for Error Indication
Aria-invalid=true
Setting aria-invalid to “true” is a quick and easy method for indicating that a field has failed validation. Yet, its usefulness from an accessibility standpoint is limited to a situation where:
- The identity of the failed field is so obvious visually, and
- No explicit description of the error is really necessary.
Examples include fields whose label / instructional text expressly indicate:
- Data format for date, email, phone numbers etc.
- Minimum – maximum range of expected values
Sometimes the placeholder or default text may also indicate the expected data format before a user attempts to fill in the field (care should be taken to ensure this is accessible). Depending on the context, the data format or expected range may be obvious or clear by general usage and may not even be stated explicitly in all situations.
- Aria-invalid may also be set on “required” fields when a user omits to complete the field.
Error Notifications
When a field has aria-invalid set to “true”, VoiceOver in Safari announces “invalid data” when the field gets focus; JAWS and NVDA notify the error as an “invalid entry”. For vision impaired users of ARIA-enabled assistive technologies, these notifications are critical for identifying fields that have failed validation in the above situations.
This ARIA attribute has to be set / turned on programmatically. It should not be set to “true” before input validation is performed or the form is submitted. Setting aria-invalid to “false” is the same as not placing the attribute for the form control at all. Quite understandably, nothing is conveyed by assistive technology to users in this case.
When it is necessary to identify the field that failed validation along with a clear error description, setting aria-invalid to “true” is redundant and does little from a viewpoint of accessibility compliance. In such a case, conveying that an error has occurred and tying the detailed error message with the relevant field programmatically will meet the requirements of SC 3.3.1 and SC 1.3.1.
When the suggestion for fixing the error is presented to the user (in order to meet SC 3.3.3, Level AA), it might be worded in a manner that describes the error too. Here again, aria-invalid=”true” is superfluous.
In example-1, aria-invalid is used when the personal identification number (PIN), email address, or start date are not in the expected format. An error message is associated with the field using aria-describedby when there’s no input for the first three fields or the requested start date is in the past.
In example-2, aria-invalid has been used on required fields that have no input.
Reference:
- Supported States and Properties: WAI-ARIA 1.1
- Aria-required=true: WCAG 2 Compliance versus Best Practice
Sailesh Panchang
Principal Accessibility Consultant, Deque Systems
