Making Multiple Input Form Fields Accessible (or More Accessible!)

First Name:

<label for="txtFirstName_1051215_447">First Name:</label><br />
<input class="input" type="text" title="Please enter your first Name" maxlength="" name="txtFirstName" id="txtFirstName_1051215_447" value="" />

The label tag is essentialy a sign post that says "All this text in here ... well it all relates to that input just there". When a screen reader is used, the user will typically tab through the page and upon reaching the form input, the screen reader correctly identifies the purpose of the field. This is great - instead of just reading out "edit" (as Jaws does), it will read "First Name".

The problem with multiple inputs

This is all well and good, but what happens when you have something like this? [Please note that there is no accessibility mark-up applied to the next example - purposely!]

Telephone Number (Country, area code and number):

It will be very difficult for screen readers to relay what each field requires, and so this needs some work. We have a few options available:

1. Use one label, apply it to the first form field only
2. Merge your separate form fields so that one field captures all data required
3. Label each field as per W3C guidelines (BEST!)

1. Use one label, apply it to the first form field only
If you have three form input fields - and the design of the page as it's been given to you states that you should have one title for the three fields (this is very common), what do you do?

You could apply a label to the first field only, but would does this work? The answer is probably yes. Not because it�s correct code-wise, but more because blind users tend to work out their own strategies for dealing with troublesome forms like this one. This approach at least offers some accessibility concessions - it's better than providing no labels at all, but hardly perfect.

To help even further though, you could use the title attribute in all three fields, as many screen readers can access this information. So, our three inputs now look like this:

Telephone Number (Country, area code and number):

<label for="ex2field1">Telephone Number (Country, area code and number):</label><br>
<input type="text" id="ex2field1" name="txtCountryCode22" value="" maxlength="4" title="Country code" />
<input type="text" name="txtAreaCode22" value="" maxlength="5" title="Area code" />
<input type="text" name="txtTelNo22" value="" title="Telephone number" />

2. Merge your separate form fields so that one field captures all data required
This is a simple approach, and one that may not be acceptable to many. The notion is that you drop separate fields and let the user decide how they enter the data. Scary, eh? Separate fields allow you to validate data entered more rigorously, but this method does not - bear it in mind.

An example of the simplified telephone number field - which will be much more difficult to validate - is as follows:

Your Full Telephone Number:

Please enter country code, area code
and local number separated by spaces

The code for this would look like this:

<label for="txtTelNo_611245_6451">Your Full Telephone Number:</label><br />
<input type="text" name="txtTelNo" id="txtTelNo_611245_6451" value="" size="40" title="Please enter country code, area code and local number separated by spaces" />

So with this approach you pass the Bobby tests by providing a lable, but probably fail in capturing data that you really want in the format that you want it. Perhaps it's time to accept the fact that the way to make the form inputs accessible is to follow the rules to the letter!

3. Label each field as per guidelines
If you follow the rules, you will use a label for each and every input. This may go against the design that you have given, and it may look downright ugly in many cases (i.e., you may have a long label for a field that only needs to accept 2 or 3 characters). In our telephone example, we'd end up with something like this

<table summary="Layout table used for visual presentation of form details">
<tr valign="top">
<td>
<label for="txtCountryCode_611222_5284">Country Code:</label><br />
<input type="text" name="txtCountryCode3" id="txtCountryCode_611222_5284" value="" maxlength="4">
</td>
<td>
<label for="txtAreaCode_611223_-49">Area Code:</label><br />
<input type="text" name="txtAreaCode3" id="txtAreaCode_611223_-49" value="" maxlength="5">
</td>
<td>
<label for="txtTelNo_611223_4117">Telephone Number:</label><br />
<input type="text" name="txtTelNo3" id="txtTelNo_611223_4117" value="">
</td>
</tr>
</table>

You don't need to worry about putting title attributes in this case. (although it can't hurt to).

So, we have a set of input fields that are accessible but which will probably irritate the designer immensly. What can you do about this? Unleash the power of Cascading Style Sheets (CSS).

hiddenlabel Labels

In your CSS file, declare a new class like so:

label.hiddenlabel {
display:none;
}

Although it is set to not display, the screen reader is able to match up the input to the label, as the label tag is still present in the HTML. You then apply the class to the labels that you wish to hide. In addition, you'll need to add a further piece of text in front of the three fields that will not be hiddenlabel - and this will NOT be a label.

<table summary="Layout table used for visual presentation of form details">
<tr valign="top">
<td>
<label for="txtCountryCode_611222_5284" class="hiddenlabel">Country Code:</label>
<input type="text" name="txtCountryCode32" id="txtCountryCode_611222_5284" value="" maxlength="4">
</td>
<td>
<label for="txtAreaCode_611223_-49" class="hiddenlabel">Area Code:</label>
<input type="text" name="txtAreaCode32" id="txtAreaCode_611223_-49" value="" maxlength="5">
</td>
<td>
<label for="txtTelNo_611223_4117" class="hiddenlabel">Local Number:</label>
<input type="text" name="txtTelNo32" id="txtTelNo_611223_4117" value="">
</td>
</tr>
</table>

For browsers that support CSS, the labels will disappear - but if they do not support CSS you do not unduly harm the layout of the page (although it may look like you're repeating yourself!)

Conclusion

Rules are there for a purpose, and we should all do our utmost to ensure that we code to standards. However, there are times where those standards can contradict design requirements, and the choice is either to ignore coding standards and deliver something as designed, or to stick to standards and tell the designer why the required design is not workable. Not many people opt for the latter, so it's useful to have a trick up your sleeve that let's you satisfy both criteria.