Forms are not required to be complicated, but many times they are because the designer and the developer may not be familiar with accessibility. Often times this manifests with an input using a placeholder as its only visible label. In this session, we hope to provide some of the most common issues found when manually testing for accessibility on forms.
Quick Dos and Don’ts
- Do ensure visible labels are present at all times and they match the accessible name
- Do not create different experiences for mouse users and keyboard only users
- Do ensure every element’s accessible name is unique
- Make sure the form layout is logical
- Make sure elements are properly grouped with fieldsets when necessary
Form fields must be accompanied with a programmatically associated label. This is accomplished best by using the “label” element with the “for” attribute set to the unique “id” value of the associated “input” element. This is important because your user may be using assistive technology to interact with the element. It could be by using Voice to text technology, and those labels are paramount to supporting them.
Accessible names can be accomplished various ways but in the end, they should be unique and present. How the developer accomplishes that task can vary depending the situation. We described one way above. Another way is to use the “aria-label” attribute. It will override the accessible name when present. This is a good way to override “Read More” visually with “Read more about Accessibility” when you have multiple “Read More” links or buttons on a page.
Color contrast matters for your interface and in regards to your inputs, you should make sure you have a 3:1 color contrast on the input boundaries with the background color. This allows the sighted user the ability to understand the form field exists, or they may miss it.
Error handling can be accomplished many ways, but ultimately the error message must be associated with the input. The best practice for error messages is to have them come directly next to them or below them visually. One thing we see many times is the error message is red and bold in nature. Seems like a great solution, but it is not programmatically associated. By adding a unique “id” to the error message block and an “aria-describedby” attribute set to that id’s value, it will connect them properly and read them in the correct order for screen reader users.
One issue often overlooked is the perceivable nature of the error message. Using color only as an indicator of communication is problemmatic for screen reader users and users who are colorblind, so the developer needs to provide a secondary indicator. Usually, we recommend either adding, “Error:” in front of the error message, or an icon with the alt text of “error” at the beginning of the message.
Sometimes an input could be better supported with instructional text. When this is present, the developer will need to programmatically associate it, as well. Using the “aria-describedby” or “aria-labelledby” attribute will accomplish this properly. Remember it will be set to the unique id value of the instructional block.
The Final Word
Follow these tips on your form fields and you will remove 90% of the accessibility issues that may be present. There are special situations, but this will move you far on your accessibility journey.