Form submission errors are a common problem on the web. Despite Developers best efforts to create simple and intuitive forms, users often enter incomplete or inaccurate data. The more complex the form, the more chances for user error.
Most web users are familiar with the messages prompting them to fill in a missed query or to edit faulty data. If there is no message guiding the user to the error, this may create confusion or distrust and cause the user to abandon the experience. Imagine the frustration caused by a complex form which would simply fail, with no indication of where the error had originated, or would proceed through multiple phases, but then fail to process in the end with no explanation. Few users would have the time or patience to persist.
For the estimated 246 million people worldwide that have severe visual impairments, this scenario is commonplace when using a screen reader. This is especially true for forms that collect data asynchronously. Without a page refresh a screen reader user has no indication that anything has happened at all. This is especially frustrating when using these forms may be the best or only option for participating in school, work or administrative tasks. Digital data has revolutionized the way the visually impaired can participate and communicate on many levels and thoughtful, accessible design is needed to facilitate these possibilities. Including these considerations in the design process ensures that users with low vision are not excluded and is required for Section 508 compliance.
Fortunately, there are ways to inform users with vision impairments about invalid inputs. By default, screen readers written using the proper markup will announce actionable elements. Screen readers will also announce elements with certain ARIA attributes applied to them. By using these methods properly we can help non-sighted users easily identify errors in inputs.
ARIA is an acronym for accessible rich internet applications. https://www.w3.org/WAI/intro/aria These html attributes were developed to aid impaired users to navigate web sites and applications.
ARIA Live Error messaging
Screen reader error messaging block
When a sighted user submits an invalid form they are usually given visual error messaging that tells them what is wrong. The same should be done for a screen reader user. This can be achieved by creating a block of html to store errors just for screen reader users. This block of html should be hidden from non-screen reader users so there are no duplicate error messages displayed and should only be available to screen reader users when errors are present.
If the form contained several errors it could be difficult for a user to retain all the messages at once and then fix them. It would be better to give the user an overview of how many errors there are and the option to go and fix them one at a time. This can be done by making the overview message a link. The overview message link would focus the first input error message, then the input error message link would directly focus the user to the invalid input.
This video has sound so turn up your volume 🔈
The user flow
- User submits an invalid form
- User is focused on the overview message link and the screen reader announces:
There are n errors in the form you submitted. Review Errors.
- User selects the overview message link
- User is focused on the first error message link and the screen reader announces:
Name is required. Fix invalid input
- User selects the error message link
- User is focused on the first invalid input and the screen reader announces:
Name is required, Fix invalid input
- add a HTML link tag at the top of the form to hold the overview message link.
- add a HTML block of input error messages for each input in the form below the link. Create a way to map the messages to the form inputs. In this example I’m using data attributes.
- hide the messages from both screen reader and non-screen reader users with CSS
- create a screen reader only class - (lifted from bootstrap) and apply it to the .message-link and .message-list
- on submit validate the form and handle the errors (In this example I’m using built in browser validation, for production code you would want a more robust solution.)
- handle the click event on the error overview message link and focus the first input error message
- handle the click event on the input error message and focus the input
These simple changes ensure that all users have a positive, or at least functional experience using the form as designed. By making accessibility consideration a norm in development we optimize web use for the greatest number of users. While this post is directed specifically at low vision users, this format could be used by people who understand a spoken language, but do not read it well and, as web use moves away from keyboard-based communication, auditory input will become more important in common use.