Better Accessible Forms

First Name:

Your life story:

Favourite Town:
Please Select ... Swindon London Burkino Faso

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

Age:
 Under 30
 Over 30

What colours do you like:
 red
 green
 blue
 purple

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.

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:
"Edit"
"Edit"
"Edit"
"Edit"
"Edit"

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.

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 {
font-weight:bold;
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:

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

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:

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.