Better Accessible Forms

Posted on: 08 December 2002

Ask anyone who has had to fix a web site that is littered with accessibility howlers, 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 problems.

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 the audience, 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 is 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:


What colours do you like:

This may seem like common sense but people repeatedly make the mistake with radio buttons of putting the control 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.
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 - to actively go and find the preceding text. This is why the <label> tag is so essential for getting 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 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:

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

A full list of example form elements, marked up with the <label> tag, is available here.

More helpful labels

As with most HTML tags, you can apply styles to the <label> tag using Cascading Style Sheets (CSS) quite easily. It may be enough to use a bold weighting for the label text to make it stand out from other text in the form. However, there is another trick that you can employ for the <label> to make it a more appealing for sighted users.

A <label> not only makes it easier for screen readers to identify what the input is, it also gives the sighted user a larger area to click on with their mouse. This is particularly useful when employed with checkboxes and radio buttons. No longer do you have to move your troublesome mouse to a tiny little spot on the screen to activate the control - now the whole wording is clickable! And if you think about this - most software applications have done this as standard for years.

Software applications have made it easier to select checkboxes by making the whole of the associated text clickable
Software applications have made it easier to select checkboxes by making the whole of the associated text clickable.

Now you can make the associated text clickable in HTML forms
Now you can make the associated text clickable in HTML forms.

Incidentally, there is a law known as Fitt's Law which states that : "The time to acquire a target is a function of the distance to and size of the target." - and here is a great example of improving the usability (as well as the accessibility) of your form.

However, if you use a label, and sighted users don't know that the associated input text is clickable, then they won't get this advantage. Well, you can suggest something's clickable for them ...

label {
cursor:pointer; }

Now, when the user hovers over a label, the cursor changes to a pointer which seems to say "Ooh, ooh, click me, click me!" at which point the user discovers that the text can set the focus to that field.

Note that some people will argue (correctly) that this goes against usability principles, in that the hand suggests a link (I agree). However, I would argue that as long as your link style is different (and consistently so) from your label style, this should not be a problem. People will very quickly learn that the result of clicking on text above the field sets the focus to that field.

Laying out your form

My best advice for the overall layout of a form is to keep it clean - leave some breathing space around inputs, and don't cram it with explanatory text. If you must provide help, do it subtly (perhaps linking to a separate help file to reduce on-screen clutter).

I always find that forms that have a clean solid background colour that differentiates itself from the document background colour works nicely. It says to me "This is the area that you need to do something with." A pastel shade, grayscale or something similar works quite nicely.

Almost always, you will opt for a table to present form inputs to get everything to line up correctly. There is no problem with this, as long as you check your table in a linearized view (see the links section at the end of this tutorial). The WORST thing you can do is put the text for each form input in separate cells from the inputs themselves, like so:

Input text: Input text: Input text:

Screen readers will have real difficulties with this, as will text browsers such as Lynx. The advice is simple - keep them together! If you do use a table layout like the one mentioned above, you will get this kind of problem:

New York Times' registration page - works poorly when linearized
New York Times' registration page - works poorly when linearized

The following two tables would not have the same problems as demonstrated by the New York Times' registration page above. In these examples, the text would appear next to the correct input field. However, if you are using the <label> tag correctly, you really should have no problems whatsoever with screen readers:

Input text:
Input text:
Input text:

Input text:    Input text:   

Logical grouping of items

We now step slightly out of the realm of accessibility and into the realms of general usability. Or, some might argue, into the world of common sense.

People hate filling in long forms. People hate reading long blocks of text (particularly on screen). But just as you can insert paragraph breaks at appropriate points in a block of text, so you should with forms.

  • Think about all the data you're collecting then try to group them into smaller chunks
  • Break these chunks of data up into clearly defined areas on the form or
  • Break these up into separate forms (remembering to clearly inform users where they are in the process - "Step 1 of three: your personal details")

Already this will make a big difference. But there's another neat trick you can use - the little known (or at least little used) <fieldset> and <legend> tags.

<fieldset> lets you bind a group of form controls together visually. In theory, screen readers should also be able to identify this fact, but for the moment, support for fieldset is very limited.

<legend> is simply a tag that you use alongside (or rather inside) the <fieldset> tag - to give the group of form controls a heading.

You are most likely to use the <fieldset> tag with radio buttons or checkboxes, as shown below, but equally, you could use the <fieldset> to group whole chunks of data collection.

My Radio buttons

My Checkboxes



A form can be presented in countless different ways, but there are some basic things you need to do to make it accessible. But like anything, there are some special touches that you can apply to make your forms that extra bit clearer, usable and accessible. You probably have your own ideas, some additional tricks that you have up your sleeve. If so, why not share them!

Further reading:

This article was written by Ian Lloyd. Ian works as a senior web designer at Nationwide Building Society where they take the matter of accessibility very seriously. Outside of work, he enjoys a spot of scuba diving and travelling.