How to use HTML to create forms that are easy to use

Aim

This lesson looks at how to create forms that look good on the page, are easily used by everyone (including disabled people), and also give users a chance to confirm or change their input.

About Forms

Forms enable you to obtain information from your visitors. That information will be more reliable if the form is designed in a logical format and includes a feedback process that checks the input data and allows the user to confirm or change the inputs before final submission.

PROCESS OF FORM COMPLETION AND SUBMISSION

The flow chart below shows a typical sequence for checking that a form has been completed satisfactorily prior to submission.

Flow chart of form submision process
Flow chart showing steps required for reliable form submission

The form sends the collected data to your server where it can be checked for completeness. Using an application such as PHP, CFM or ASP.NET your server can process the data and work out if the form has been completed reasonably well. If so then the server returns a page that allows the user to confirm the details before final submission. If the application suspects a fault in the data entered then it should return a page that identifies the fields that might need attention with some appropriate tips to help the user complete the form correctly. We shall look at how to provide these tips on page 2. The essential thing is that you allow the user to check and confirm the data being submitted before it is finally sent to your database.

STEPS TO DESIGNING AN ACCESSIBLE FORM

  1. Decide what information you want the visitor to provide
  2. Arrange the required inputs in a logical (intuitive) sequence
  3. Decide which fields are required and which are optional
  4. Decide how you are going to validate the form
  5. Write the HTML code for the form
    1. Form action should include a checking process to allow the user to correct or confirm inputs
    2. Field labels, and any tips for completing the field, should precede input field
    3. Field labels should be tied to input field using the <label> attribute.
    4. Complex forms should be divided up using the <fieldset> and <legend> elements
  6. Use CSS to lay the form out in a suitable format for visual users

FORM CONTENT

People can feel that forms are quite intrusive, so only ask for the information that you really need. Avoid confusion by making it very clear what information you require. Use descriptive labels for the input fields that clearly explain what sort of information you require at that point. Provide explanatory text if required to help the user complete the form correctly.

Form components

Forms consist of one or more form controls where users can enter information or select options. Most form controls consist of a descriptive label that tells the user what information is required and an input field that accepts the user input. The exceptions are hidden form controls that are used for administrative purposes and the Submit and Reset buttons that activate or clear the data from the form. For all the form controls where a user is expected to enter data it is important to place the descriptive label immediately before the input field (both in the code and on the screen).

Label element

As an extra aid for disabled users the field label (instructions) should be tied to the input field by using the <label> element. There are two options for using the <label> element. Either enclose both the label and the input field within the <label> elements, or tie the label to the input field using the for="" attribute. Both of these options are shown below, but we recommend that you normally use the second version (using the for attribute) as it allows you to layout forms using a table or move the label visually to the right of the input field.

<label>Your Name <input type="text" name="name" id="name" /> </label>

<label for="name">Your Name</label><input type="text" name="name" id="name" />

The <label> element has two advantages for disabled people.
1. It allows blind people to hear the label repeated when they select the input field
2. It enlarges the focal area of the input field so that mouse users have a larger selection area, People with weak eyesight can click on the label or the input box to select the relevant input field.

According to the W3C, when using the <label> element with the for="" attribute. the for value should be tied to the “id” attribute of the input element. However some older browsers only recognise the “name” attribute. For this reason it is safest to include both the “id” and “name” attributes. Take care that the values of these attributes are identical to the value of the “for” attribute of the <label> element.

Radio buttons and check boxes

Input fields known as radio buttons are groups of mutually exclusive options where only one button within that group can be selected. These are coded as follows.


<label for=”male”>Male:</label><input type="radio" checked="checked" name="Sex" id=”male” value="male">
<br /><label for=”female”>Female: </label><input type="radio" name="Sex" id=”female” value="female">

Note that the label is only tied to the “id” attribute of radio buttons. The resulting output will look like this :

Gender
Using CSS to repostion the label element

If you have a long list of radio buttons (more than three items) visual users find it easier if the button box is positioned to the left of the label text. This often makes the page layout neater as well. However blind users still need to hear the label text before they find the button. The best solution is to write the label first in HTML and then use CSS to position it to the right of the radio button (e.g. two or three ems from the left margin).

label { position: absolute; left: 2em; }

Because we used the absolute attribute the label moves to the right leaving a space at the left of the page that the radiobutton fits into. An alternative method is to "float" the radiobuttons to the left of the label using CSS, but this can be unpredictable. Note that this visual re-alignment is only possible if we use the <label for="xx"> version of the label element. If you surround both the instructions and the input field with a simple <label> the input field will remain positioned to the right of the instructions.

Gender

An optional extra (if the radio button is important) is to include the “title” attribute to the input element. Many blind users have the title facility enabled on their screen readers so they can hear the title read out as they select a radio button. However this is not a universal fix as not all assistive software reads out the title.

Checkboxes

Checkboxes allow users to select more than one option. Keyboard users tab through the options and press the space bar to select any they require. The rules for accessibility are the same as for radio buttons, but you can also use the “name” attribute as a link for the label element as checkboxes do not need a common name.

Selection groups

The select element allows the user to select one option from a pull-down list. The rules for accessibility are the same as above. To help users we can include the <optgroup> attribute to group together similar options. It is not neccessary to enclose a single option group within a frameset.

<label for="select">Colour</label><select name="select" id="select" >
<optgroup label="Gloss">
<option value="G_Red">Red</option> <option value="G_Blue">Blue</option> <option value="G_Green">Green</option>
</optgroup>
<optgroup label="Matt">
<option value="M_Pink">Pink</option> <option value="M_Red">Red</option> <option value="M_Blue">Blue</option>
</optgroup>
</select>

The standard HTML select element produces a small black down arrowin the right hand button that mouse users can click on to bring down the list. Keyboard users however just tab into the select window and use the cursor keys (up & down arrows on the keyboard) to scroll through the list of options.

Text, password and textarea fields

Text and password fields accept only a single line of text. The difference is that the password field hides the input from the user by displaying a series of asterix (*). The password input can be hard for people with dyslexia to complete correctly. For non-secure applications (where the purpose of the password is to help identify someone for purely administrative purposes) it is better to allow passwords to be entered in a normal text box. For financial (e.g. banking) services a hidden password may be essential. In this case you should consider providing an alternative method of identification or method of sending a reminder. Please do not simply lock someone out if they fail to complete a password correctly.

Textarea fields accept any amount of text. If you expect that your users will be typing more than a few lines within a textarea field you should specifically format the textarea element using CSS so that users can clearly see what they are typing into the box. If you fail to specify a font and line size to this element it will use the current (default) font which might be quite difficult for the user to read.

All other accessibility issues are the same as for radio buttons and check boxes.

Using the fieldset and legend elements

Form controls can be grouped by enclosing them with the fieldset element. All controls within a given fieldset are then related. This provides a semantic grouping for related form controls. Thus allowing users to understand the relationship of the controls and interact with the form more quickly and effectively.

The first element inside the fieldset should be a legend element. This provides a label for the group in much the same way as a heading.

Grouping controls is most important for related radio buttons and checkboxes. A set of radio buttons or checkboxes is related when they all submit values for a single named field. Because they are multiple controls with a common theme it is important that they be grouped semantically. Some assistive software will present the value of the legend before the label of each control, to remind users that they are part of the same group. It can also be useful to group other sets of controls that are not as tightly related as sets of radio buttons and checkboxes. For instance, several fields that collect a user's address might be grouped together with a legend of "Address".

By default the fieldset element draws a border around the grouped items. You can over-ride this style settings, but this visual grouping is useful for sighted users.

Fieldsets can be nested if desired, although this can lead to confusion if overdone.

These extra notes are designed to help you improve the reliability and usability of your forms. This will enable disabled users to complete your forms as easily as other users.

Improving Forms

Providing additional guidance for input fields

If you need to include additional advice to help the user complete an input field correctly this advice needs to be written in the HTML before the user reaches the actual field.

<label for="email">Your e-Mail address - </label>
<span id=”helptext1”>(Please provide a valid email address)</span>
<input type="text" name="email" id="email" /> </p>

(Please provide a valid email address)

We can then use CSS to position the help text to the right of the email input box for visual users.

<style type="text/css> .helptext {position:absolute; right:25em; } </style>

The result now is that the "help text" is sent off to the right of the input field (25 characters from where it was), whilst the input field slides in to fill the space left. Screen readers and text only browsers will still read the help text before the user enters the input box. The result for visual users is shown below.

(Please provide a valid email address)

You can add further styles to the help text to make it more noticeable to visual users.

Providing even more detailed information

Sometimes you may want to add extra supporting informationIf you have a form that might be used quite often by the same people, but want to add detailed information for first time users

Formatting input field text

When your visitor types text into an input field they need to be able to see what they have written so they can check spelling etc. Input fields are elements (blocks) just like the <p> element, so they need to be specifically formatted in the stylesheet. If you do not specify a font-face or font-size for input fields the default setting of the <body> tag will be used. We recommend that you always define fonts and colours for the input element. To help make the input stand out from the main page content we suggest that input fonts should be slightly larger than the currently declared font face (e.g. 1.2em). Type something in the input (email) field above and then type something into the box below and see if it is easier to read when it is made slightly larger..

You can format input fields just like any other block element, but don't get too carried away. If the input boxes are too noticeably different to the overall form design users can become distracted and not read the field label instructions properly.

Providing alt tags for submit buttons

The "Submit" and "Reset" buttons are usually coded with a "value" attribute that is displayed on the button as displayed below.

-

It is a good idea to use a slightly more meaningful values for these buttons such as "Press to submit this form" and "Press to clear the form and start again". The style of the button can be redesigned with CSS, or even use specially designed images. If you do not use the standard buttons as shown above it may be necessary to provide an alternative text tag to replace the "value" attribute. You can technically add an alternative text tag to a standard button, but blind people may hear both the value and the alternative text read out which can be confusing, so only provide the alt tag if you have not used the value attribute to display a text message on the button.

 

Tab index

Selectable HTML elements such as links and form fields can include the tabindex attribute. This attribute controls the order in which the elements are selected by keyboard users. It has no effect for mouse users. If the HTML has been written in a logical order there is no need to use the tabindex attribute as the user will follow a logical path without it. In fact the tabindex attribute can cause real frustration for disabled users if it is not implemented correctly. The tabindex attribute takes control of events away from the user and can leave the user not knowing where the current focus is. We therefore recommend that you do not use the tabindex attribute.

Using the server to validate the form

If your server runs an application such as PHP, ColdFusion or ASP you can design a method that automatically checks that the input is what you expect. For example you can check if any fields are empty, or if an email field includes at least one @ sign. You can then write a programmable script that designs a new page for the user that identifies any potential errors. It is important that you design a system that clearly identifies what the errors were, where they were and how you think the user should correct them. Please do not rely on statements such as "the items in red need attention" or "You have not completed all the fields". Please try to be specific about your instructions by using phrases such as "Please provide a valid email address in the third field" so that the user knows where to go and how to make the correction.

Using java to validate form

If you do not have access to a webserver that runs applications such as PHP or APS.NET then it is possible to use some javascripts to check that a form has been completed before submission. This is not a very reliable solution as some assistive software does still not work with javascripts.

Any reputable hosting service will provide PHP or similar as part of their standard package, or allow an upgrade for a small fee. Our recommendation is to use one of these server-based programmes instead of javascripts for form validation.

USING TABLES TO LAYOUT FORM FIELDS

If you have to use a table to layout the form on the page it is vital that the field label is either in the same cell as the input field, or in the adjacent preceding cell.

This is correctThis is wrongThis is correct
First Name input box
Last Name input box
First Name Last Name
input box input box

First Name
input box

Last Name
input box

In the second (middle) example there is no logical connection between the label and the input field which the screen reader can identify. Whilst using the <label> element here would help most assistive software some basic screen readers would still follow the table format, plus the code is harder to maintain as the relevant inputs do not follow immediately after the label.


Lesson Summary

This lesson has looked at how to create accessible forms

  1. Design forms to only obtain the information you really need
  2. Arrange the form fields in a logical order
  3. Position meaningful labels before input fields
  4. Use CSS to position radiobuttons and checkboxes visually if you want them to appear to the left of their label
  5. Use the fieldset element to group together related input fields
  6. Use a server to validate form input and provide meaningful guidance to the user for error correction
  7. Use CSS to format input fields so that user input is clear
  8. If possible avoid using the select element
  9. If possible avoid using the tabindex element
  10. If possible avoid using javascript to validate forms
  11. If you use a table to layout your form, make sure it makes sense when read cell-by-cell.