Tables and forms
Designing tables
Tables are designed to be used only for showing data. However, they are widely used on Web sites to control layout. Using tables for layout is now being phased out because of improvements to browsers and the layout techniques that can be achieved using style sheets.
Guidelines for creating data tables
Avoid designing complex data tables. They can cause usability problems for all users and are particularly difficult to markup for screen reader accessibility. Sometimes complex data is best communicated with a diagram or visual representation of some kind.
The most important thing for accessibility of data tables is to make sure that the content is read or presented in the correct order. In browsers that do not support tables the information is treated as a series of paragraphs. The paragraphs are read in a particular order, starting with the top left cell. You can check the reading order with a tool like The Wave.
Structural markup should be used to distinguish table header cells from data cells. Header cells should be marked up with <th id> and data cells should be marked up with <td headers>. Each data cell references the relevant headers, for example:
<th id="monday">Monday</th>
<th id="low">Low impact</th>
<td headers="monday low"> 10am </td>
Tables should also include an appropriate summary attribute that describes the content contained in the table. For example, "Aerobics class sessions, Monday to Friday".
<table width="100%" summary="Aerobics classes and session times.">
Another way of providing summary information for a table is to give the table a title using the <caption> element.
<table width="100%" summary="Aerobics classes and session times.">
<caption>Class times</caption>
Designing forms
The following guidelines will help you design forms that are accessible and work in a variety of browsers.
Position labels for form elements carefully
Position labels so that they are read out immediately before the form input field. In most cases, this means placing the label above or to the left of the form input field. For radio buttons and checkboxes the label should be positioned immediately after the form input field.
Doing this will make content easier to scan and improve readability for sighted users. It will also ensure the reading order for screen reader users is correct.
The disadvantage of a vertical design is the increased length of the form. You may find it better to split the form into more than one page - although this means that you will need to pay particular attention to navigation through the different pages of the form.
Use <label> to explicitly associate the form label with the input field
To associate a label with a form input field, use the <label> element. The association is made by copying the form identification (id) attribute to the for attribute in the label as shown below.
<label for="fname">First name
<input type="text" id="fname" name="firstname" size="20" /></label>
If you are using a table to layout the form this is how to associate the form label with the form input field:
<table summary="Layout table for name details."> <tr> <td><label for="fname">First name:</label></td> <td><input type="text" name="firstname" id="fname" /></td> </tr> <tr> <td><label for="lname">Last name:</label></td> <td><input type="text" name="lastname" id="lname" /></td> </tr> </table>
Grouping form fields
Grouping fields using fieldsets
Often forms are made up of two or more sections. On an event booking form there might be fields to collect your contact details and fields collecting information about the events you wish to attend. Use of headings to group these sections is a quick and easy way that can make the form easier to understand.
Another way of grouping form fields is by using the <fieldset> element. By default this is visually displayed in a browser as a solid line around a number of form fields with the legend text intersecting top of box.
Grouping menu options
If you have a menu form field that contains multiple groups of information, they can be grouped using the <optgroup> element. These groups will be displayed in the browser as a dropdown menu with bold group headings and indented options like so:
Indicate mandatory fields using the word "required"
Mandatory fields must be labeled with the word "required" immediately after the field name and within the actual field label.
In addition to this, mandatory fields can be also marked up as a different color (eg. red) to enhance visual identification, but color must not be used as the only means of conveying a mandatory field.
Use HTML buttons rather than image buttons
Using images for buttons cause difficulty for users who need to increase the text size or use a screen magnifier. Images don't enlarge well because the text can become jagged and difficult to read. If styles and markup are used to create the button when the text size is increased, then the text size on the button will also gracefully increase. Images can be included as backgrounds to form buttons achieving a blend of visual cohesiveness and usability.
If you must use an image make sure that the alt attribute contains meaningful description. For example:
<input type="image" alt="Submit!" border="0" name="imageField" src="/assets/images/submit.gif" width="109" height="41" />
Don't add "Clear" or "Reset" buttons to your form
While there may be forms that require a "Clear" or "Reset" button, the majority of forms don't and will not benefit from having these buttons added. The reasons being:
- Users can click the button by mistake.
- It's an extra button to clutter up your form.
- It presents an extra choice that users have to think about.
- It makes the submit button less visible.
- Amending one field is quicker than re-entering the data for an entire form if you've accidentally hit the reset button.
