Example Form Validation, With Section Error
The form below uses multiple techniques to indicate form field errors.
- When blurring out or when an error is detected, the field border and labels become red and slightly bolder in appearance.
-
When blurring out of a field in which the required pattern has not been met, a caution triangle glyph
(⚠️) with text alternative of
Error:
and a red error message is associated with the field. -
When blurring out or when an error is detected,
aria-invalid="true"is injected into the control. -
Both error and helper text are associated with the fields using
aria-describedbyso that screen readers can provide context to users when they interact with the fields. -
On blur (only), an
aria-liveregion is populated with a message announcing,Error in previous field, [text of error message].
- When clicking the Submit button, if the user has not filled out the form correctly — that is, there are one or more errors — focus goes to the first field with an error, and a live region message will announce to screen reader users, indicating how many errors are present in the form.
-
aria-liveregions are set aspoliteandaria-atomic, so that the screen reader will finish what it's currently announcing before it announces the new message, and the entire message will be announced. -
When the form has been correctly filled out focus will go to a mock system error, in a
divabove the form. Since there is change of context that accompanies this new content, there is no live region announcement. -
All fields are assumed to be required, unless denoted
(optional).
The required fields are markedaria-requiredfor screen reader users. Use of this attribute allows us to skirt unwanted side effects sometimes encountered with browsers/screen readers when the booleanrequiredis used. The radio button group is marked as required usingaria-requiredon thefieldset. Since a fieldset cannot be marked as required, we explicitly set theroleof the fieldset toradiogroup, which can takearia-required. -
The fields use correct
autocompleteattribute values to support browser autofill and assistive technologies that can take advantage of those attributes.
Live region messages — considered to be status messages
on this page — are on a delay of
two seconds, so that messages are less likely to get clobbered by the screen reader, which may be dealing
with announcements that result from focus changes. We have noticed some screen readers do not acknowledge
live region messages when they occur simultaneously with changes of focus.
The live region messages on this page target a single element always (no redundant or forgotten live regions
for the screen reader user to discover) and are visually hidden by default. If you want to hear the live
region messages in action, try using a screen reader to test real-world behavior. This is the best way to
test this experience, since other screen reader chatter may be present, due to things like the
aria-describedby associated helper and error message changes being treated by some browsers as
live region updates. If you want to see the live region messages visually, you can
The error and helper/formatting text below the fields are aria-hidden in order to minimize chatter when
browsing the form with a screen reader. If you want to make them always browseable by screen readers in
order to test the experience, you can
When in a text field, validation runs on each key-up event, except Tab key. So we can clear the error as soon as the field's validation pattern is met.
Note: Error checking in this form is not very robust. Most of the fields are just looking for some text to go in them, except for the email, zip, and state abbreviation fields, which match on particular patterns. There is no checking if a zip or state abbreviation is correct. The (optional) textarea field is checking for a character count. The radio button group is checking to see if one of the radio buttons is checked.