Web forms are helpful tools that allow users to provide information electronically rather than via a traditional paper form. Web forms are used in a variety of ways, including contact forms, surveys or feedback forms, event registration, or payment/order forms. While fairly easy to create, web forms can be ineffective for someone using assistive technology if they’re not properly set up.
Check out this example of a poorly constructed form:
What’s wrong with the form?
- The first field that asks for the user’s name doesn’t have a form field label, heading, subheading, or description which means it could easily be skipped by a screen reader. It’s also not clear what information is being asked without the header — first what? last what?
- The second field does include a label — phone number — with placement text showing the desired format of how you should input the phone number. However, once you start typing in the field, the placeholder text with the format instructions disappears, leaving you wondering how to finish inputting the phone number.
- The third field asks for event attendance and provides a link to the event schedule in the description — this is perfectly fine, however, if you click the link you are taken to a new page within your browser tab and have now lost your spot on the form.
- The fourth field asks which hiking trail you’d like to pursue at the event. The field has an embedded image depicting the different trail options. The problem here, while not visible on the front end to those of us not using assistive technology, the alt text on this image simply says “Arb map.” For those using a screen reader, it would be impossible to answer this question because you’re not sure of the arb trail options since the alt text provides no information that will help you make your choice.
- Another issue with this form field is the descriptive text is using an incorrect header! It might look like bolded text, but the description line is actually using an H4 header and in this case, a header isn’t needed.
- Lastly, the button to submit the form reads “See You Soon!” which is not indicative to a screen reader user what happens when the button is clicked.
Now let’s look at the same form, created with accessibility in mind.
So what was changed?
- The first field that asks for the user’s name now has a field label that tells us what information is being asked.
- The second field asking for a phone number has the requested number format shown in the description field instead of as placement text. The format instructions are now visible 100 percent of the time, even when you start filling in the field.
- The third field asks for event attendance and provides a link to the event schedule in the description. When clicked, this link opens in a new tab, allowing users to still access the form on the original tab.
- The fourth field asking which hiking trail you’d like to pursue at the event still includes an image of the arboretum trail map, however, the alt text of the image has been edited to depict the different trail options. The alt text now reads “arboretum trails map: short loop trail is 1 mile; medium loop trail is 2.6 miles of the lower arb and 1.4 miles of the upper arb; long loop trail is 4.4 miles of the lower arb and 2.4 miles of the upper arb.” For those using a screen reader, they can now accurately understand what’s being presented on the image and make a decision about which trail they’d like to select.
- The field description has also been edited — it no longer uses a header, and now provides more information needed to select an answer.
- Lastly, the button to submit the form reads “Submit” which is now extremely clear to users and screen readers what happens when the button is clicked.
Tips for making your web form accessible
- Links within a form should open in a new tab — this is contradictory to what we typically say which is to never open a link in a new tab, however, with web forms you want to open the link in a new tab so the user doesn’t lose their spot in the form. When opening a link in the same window, the user would lose their spot on the form and have to start over.
- Be sure to include proper headings/subheadings, sections, labeled form fields, and buttons. For example, keep the button to submit the form simple with just “Submit.”
- As with embedded images or graphs displayed anywhere on a website, these elements (if necessary to understand the form) should include alt-text. This ensures all users can complete every step of your form!
- Use placeholder text sparingly as it disappears when someone starts filling in the field. Placeholder text should NOT replace labels, field descriptions, or headings.
- Avoid certain CAPTCHA tests if possible. CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a type of security measure known as challenge-response authentication — otherwise known as the little puzzles at the beginning or end of forms to make sure you’re a human submitting the form and not a robot. These fields often ask users to select all the stoplights in a grid series of photos or type out a scribbled word in an image. Someone using a screenreader is unable to complete these tests making their form unsubmittable or invalid.
- Discover more tips and tricks for creating accessible forms