We have implemented required form elements and validation/error messages inconsistently across different form components. Some, like search, use client-side browser validation and aria-required is inconsistently applied. Also, we need to research if aria-invalid="false" should be set for required fields that are valid (I've seen conflicting recommendations).
Expected behavior
When fields are required or invalid, that should be clearly and consistently communicated to screen reader users.
From further research, there are some browser-screen reader combos that have previously sent confusing messages to users when a field is required and not filled out yet, stating that it is invalid before they have completed the form. However, I see enough solid advice to stick with only aria-invalid="true" and remove that attribute altogether before validation, so I don't think we need to change course.
We currently use client-side validation with the search form, but I think that's fine for now. That only comes up if someone tried to submit an empty search form.
It's fine to just use required for an input. We don't also need to add aria-required="true"
Describe the bug
We have implemented required form elements and validation/error messages inconsistently across different form components. Some, like
search
, use client-side browser validation andaria-required
is inconsistently applied. Also, we need to research ifaria-invalid="false"
should be set for required fields that are valid (I've seen conflicting recommendations).Expected behavior
When fields are required or invalid, that should be clearly and consistently communicated to screen reader users.
Additional context
A useful breakdown of a11y form basics, and also this Exposing Field Errors post