A very basic component of building an accessible website is accessibility-friendly input boxes on forms. In this post, I’ll show you how to build them.
Forms are one of the most important features on a site. They allow you to gather user information. Some are one-line forms and some are multi-level arrangements. But each form needs to be functional and comprehensible for everyone, all the time.
Example: When Input Boxes Become Inaccessible
Let’s consider a hypothetical scenario where a user (we’ll name him William) with a short term memory disability is filling out a form. He sees the header “User Information,” and a form asking for his personal information. We’re doing great so far.
William starts filling out the form and as he gets farther down he starts questioning whether he is filling out each line correctly. He scrolls back up to the form header and re-reads “user information.” At this point, here are some questions William might ask:
Why did I put my dog’s name and breed in this form if it’s about me?
Why did I just enter my city’s name? If my street address was the last thing I entered why am I entering my city now? Where should I put my apartment number?
Why did I enter a number 12?
To find out the answer to these questions, William would have to backspace on each of his responses to see the placeholder in the input field, like so:
In the case of age, the placeholder is vague enough that he may still not know the correct response.
This is the most basic level of input box and it is not accessibility friendly.
Example: An Accessible Input Box
The second type of input box is in a very commonly seen form where each input box is labeled and has a placeholder. This lets the user know what they should enter, and that what they entered was correct after the fact. This is a much better way to code a form. Even though the header could be more descriptive, the user will no longer have basic usage questions.
This is a good input box. A friendly input box.
Could it be better? Of course! This is still a very basic version (notice how age is still not clarified as to whether it is William’s age or Spot’s age?), but it will help you start thinking with accessibility in mind.
Try it yourself!
To make it easy, I’ve added this code to GitHub so you can start working on your own versions:
Breaking it down and building it up
The examples I’ve provided are common but also very simple. There are so many other instances that users could come across. Why not try coding some of these?
A group of radio buttons where the user should hear (with a screen reader) the category header before each option
A form that lets the user know that two out of seven input fields are required (did you know that screen readers only read specific elements inside forms? If you’re adding a plain <p> tag after an input box, the user may never know)
Can you move through your form and reach each input box with just your keyboard?
If you have a particularly important form in the middle of a webpage full of unimportant text, how do you get your user to skip the needless information and go straight to the form?
I encourage you to try making your own forms and testing them with an accessibility testing tool. Try inspecting forms you’ve used or seen in the past and see where they went wrong, or where they went right!
If you have questions about implementing an accessibility friendly input box or other accessible website features, don’t hesitate to reach out.