Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate adding 'aria-invalid' attribute on form inputs that have errors #1168

Closed
36degrees opened this issue Jan 31, 2019 · 5 comments
Closed

Comments

@36degrees
Copy link
Contributor

36degrees commented Jan 31, 2019

What

Investigate whether adding the aria-invalid attribute to form inputs helps users using assistive technologies to identify form fields that contain errors.

Why

In GOV.UK Elements we used to suggest considering using aria-invalid:

Also consider using the aria-invalid attribute to programmatically indicate that a field has an error. The value of the aria-invalid attribute will vary depending on the type of error.

http://govuk-elements.herokuapp.com/errors/example-form-validation-single-question-radio

This information is not in the Design System. We should consider if this advice is still relevant, and, if possible, make it clearer and provide examples. For example, in which situations is it important to use the aria-invalid attribute?

Who needs to know about this

Developers

More information

Using aria-invalid to identify error fields is one technique that can be used to meet Success Criterion 3.3.1: Error Identification. This criterion was present in WCAG 2.0 – it is not part of changes introduced in WCAG 2.1.

The guidance on using this technique states that:

Its use is most suitable when:

  • The error description does not programmatically identify the failed fields

  • The failed fields are identified in a manner that is not available to some users - for example by using an error-icon rendered visually by some technique that does not rely on color such as a visual cue like a border.

https://www.w3.org/TR/WCAG20-TECHS/ARIA21.html

Based on this description, it appears that we may not need to add aria-invalid because we are already using multiple other techniques to identify errors:

  • The use of the error summary component, with role=alert, which describes any error(s) found in the form.
  • The use of an error message component on any input with a validation error, associated with the input using aria-describedby.
  • A red border around any input with a validation error, used as a visual indicator to indicate an error.
  • A red line to the left of any question with a validation error, used as a visual indicator to indicate an error.

It may be that using aria-invalid is redundant, and may even be overly verbose for users. However, we should do the work to better understand its use and document it.

When the Design System and its examples were audited against WCAG 2.0 in June 2018, no issues relating to success criterion 3.3.1 were found. However, the rating against this criterion was recorded as 'Not Applicable (N/A)' suggesting that 'no content was found on the service to which the checkpoint would relate' – it may be that the examples in the Design System were not realistic to trigger an audit against this point.

@36degrees
Copy link
Contributor Author

Based on running git log -S "aria-invalid" it looks as though the guidance around using aria-invalid was first introduced in alphagov/govuk_elements@dcd475e.

Based on a GitHub search across alphagov repos, I can't find any issues discussing the use of aria-invalid, but it is used in a few places across the codebase.

@stevenaproctor
Copy link

@36degrees I think your idea to add a visually hidden 'Error: ' to the error next to the form field is still worth considering. This would also make the aria-invalid not necessary.

@36degrees
Copy link
Contributor Author

Based on the guidance quoted in the initial post, I am reasonably confident that aria-invalid is not something we need to add to invalid fields.

It'd be good if someone else could take a look at the guidance and see if they come to the same conclusion.

@NickColley
Copy link
Contributor

NickColley commented Jan 23, 2020

I agree, it seems like this attribute can be used as a last resort, if there's no descriptive error already.

While it is always preferable to programmatically associate specific error description with the failed field, the page's design or the framework employed may sometimes constrain the author's ability to do so. In these cases, authors may programmatically set aria-invalid to "true" on the fields that have failed validation. This is interpretable mainly by assistive technologies (like screen readers / screen magnifiers) employed by users who are vision impaired. 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”.

Using Aria-Invalid to Indicate An Error Field

@36degrees
Copy link
Contributor Author

Thanks, @NickColley!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

4 participants