Build Accessible Online Forms

Ask anyone who has had to fix a Website that's littered with accessibility howlers, and top-most in their list of problems encountered will be forms, closely followed by tables. These two topics always seem to present the most difficulties, but they needn't be a problem. For the most part, forms are a problem because the extra accessibility tags are simply not known to the Web designer -- after all, it looks right, it seems to work... what's the problem? Only by switching off the monitor and using a screen-reader can our oblivious Web developer understand the issues.

In this guide, I will very briefly cover the basics of layout for different form elements, and one particular accessibility tag that will make the form much more usable. I'll then look at some extra ideas that perhaps you are unaware of, or didn't know were possible, that will make your forms just that extra bit usable -- for all of your audience members, sighted or otherwise.

Layout of Form Elements

Without even knowing it, many Web developers are already doing the right thing in terms of form layout - somehow, they have absorbed best practice by repeated exposure. However, people do still mistakes with some form controls. Here's a quick summary of how to set out your form elements.

For most form inputs, the text (or label) that relates to the form control should precede the control (either directly above or to the left). Or, to use some examples:

However, for radio buttons and checkboxes, the form control comes first, like so:

This may seem like common sense but people repeatedly make the mistake with of putting the control for the radio button after the text or, even worse, inline in the middle of a sentence. This can be extremely confusing for screen readers, which expect the radio or checkbox control to come first. The image below demonstrates just how difficult it can make filling in a form correctly.

The layout of these radio buttons means that a screen reader will nearly always choose yes when they really meant no.

Accessibility Tags for Forms

If you have laid out your form elements according to the guidelines mentioned in the previous section, screen readers might, just might, be able to read out the purpose of each form input reasonably well. But in most cases it will struggle, or it will force the user to backtrack at each input to get a sense of where they are -- in order to actively go and find the preceding text. This is why the <label> tag is so essential for making your form accessible.

For every form input, ensure that the associated text has a label tag wrapped around it. This label should explicitly refer to the form input.

If you do this for all your form elements, you will enhance your form's accessibility levels by 200%. The difference, as a screen reader would announce form inputs, is best described with a transcription (example shown using Jaws, tabbing through the page).

Using the <label> tag:

"Edit: First Name"
"Edit: Middle Name"
"Edit: Last Name"
"Edit: Title"
"Edit: Sex"

Without the <label> tag, it might* sound something like this:

"Edit"
"Edit"
"Edit"
"Edit"
"Edit"

*Jaws -- and other screen readers -- might still correctly read out the input fields, depending on how you have laid elements out.

So, which form would you find easier to fill in if you were hearing this from your screen reader?

Note: A full list of example form elements, marked up with the <label> tag, is available at the end of this article.