Web Access Centre

Forms - Web Access Centre

Summary: Learn about accessible forms.

Rationale
Techniques
Testing tips
Further information
W3C WAI compliance
Other pages about accessible scripts and forms

Rationale

Forms are used to allow people to place orders, send valuable data, comments and information via the web. They are also used to provide search boxes and conduct online polls and other activities where people are required to submit information.

Although the logical flow of a form can make sense when read visually, at the same time, it may be completely incomprehensible for people who use text browsers, screen magnification or speech and braille output. It has to be properly structured and optimised to support access technology. Labels for form fields, for instance, must be positioned correctly otherwise people who cannot see the visual layout will not be sure that they are inputting their data in the appropriate field.

A form can be difficult to understand and use if it is long or complex, especially for people who have problems reading. Instructions on completing the form and information on the layout and precise data required must be concise and unambiguous.

Complex forms also tend to suffer from poor linearity, especially when tables are used for layout. This has a large impact on people who use speech or braille output as it can make it very difficult or impossible to navigate or understand.

Forms often rely on functionality provided by client-side scripting such as JavaScript to perform validation, make the form dynamic or submit the form. This causes problems for people who do not have JavaScript enabled and leaves them with no way to complete the task of filling in or submitting the form.

Providing a clear, well-structured form makes it easier to follow for people who use speech or braille output and screen magnifiers. Taking the time too properly construct it will yield benefits and make it more usable for everyone. Research carried out by RNIB and Standard Life (February 2003) found that the most common place for people with sight problems to leave a website is when they are using a form. This can result in considerable loss in online sales, as people with disabilities who have Internet access tend to use the web extensively to shop.

Techniques

Clear, short instructions should be given to tell the user how many pages the form is spread over and the process for filling it out. This could be in a cover page or at the top of the first page if it is a multi-page form.

Provide further brief instructions at the top of each page of the form. For example, if the form will time-out, you should provide a message such as "You have 5 minutes to complete the transactions on this page".

Information, comments and instructions must be positioned before the form element they relate to.

Design your form so that it is easy and intuitive to complete. Which form elements to use will depend on the complexity of the required data and number of possible answers. Choose the most appropriate means of gathering the required information, for instance, choose radio buttons rather than a dropdown list if there are only two options.

Be aware of overusing radio buttons and checkboxes. These can cause problems of legibility for people with dyslexia and people with hand tremors or low vision may find it hard to use the mouse to make an accurate selection. The greater the number of radio buttons or checkboxes, generally the harder the form will be to complete.

Consider using combo boxes and checkboxes. For questions with more than three possible answers that can be checked, it becomes increasingly difficult to remember the question, especially if it is long. This is particularly important for people using screen readers, as returning to the question can be laborious and disorienting.

In addition, someone using screen magnification software may not be able to see all the options and the question at the same time, so they may not know there are more options that they can scroll to.

If radio buttons are used for simple questions requiring only a "yes" or "no" answer, there is no need to repeat the question for each choice. This can be cumbersome for people who use speech output and will hear it repeatedly.

Use appropriate spacing between elements within a form. People with mobility problems may have shaky hands and find it hard to select radio buttons when they are positioned too close together. Good judgement is needed on appropriate spacing, as people who use screen magnification can easily lose track of where they are if there is a big gap of empty space between the text label and form element.
Long or complex forms should be broken down onto separate pages of logical blocks of information. For example, personal information and business information.
Group related information using structural markup so that screen reader users are made aware of the relationships that might otherwise only be made obvious by visual layout

In the form as a whole, the FIELDSET and LEGEND tags should be used for this purpose. You can also provide headers using the H1 – H6 elements for additional structure i.e. "Personal information" and "Business Information".

Within option menus, use the SELECT, OBGROUP and OPTION tags to provide similar but more localised information.

Correctly positioned labels are essential to making forms accessible:
Input fields and combo boxes must have text labels provided on the left or above the form element.

Radio buttons and checkboxes text labels must appear on the right. This is so that, where no explicit labels have been provided, the relationship between any form element and its text label can be implicitly associated from their relative positions.

Implicit association in forms is where a piece of text , ie a label, is associated with a form element either through:

a) Their relative positions, as described above, for example:

Name: <input type="text" />
or
<input type="checkbox" /> I agree

b) By both the text and the form element being enclosed within the opening and closing tags of the same LABEL element. For example:

<label>Name: <input type="text"></label>
or
<label><input type="checkbox"> I agree</label>

Some form elements also have "implicit labels" through their VALUE attribute. For example:

Explicit association in forms is when a piece of text is enclosed within opening and closing LABEL tags, and the FOR attribute in the LABEL element is used to designate the same value as the ID attribute value used in the form element. For example:

<label for="forename">First name:</label> <input type="text" id="forename">
or
<input type="checkbox" id="agree"> <label for="agree">I agree</label>

Label all fields, especially where input boxes are grouped together such as in a date format. When accessing the page visually it is clear that the date month and year need to be filled into the three boxes. A screen reader will only associate the text label "Date" with the first text input box. The recommendation is that there are text labels for "Date", "Month" and "Year" or the LABEL tag is used. This also applies for other types of input, such as telephone numbers, and currency or decimal values.
Forms must linearize and still make sense. It is important to avoid separating related information, such as placing a text label and its form element in unrelated data cells or tables. This would make it impossible for a screen reader to understand the relationship between the two. For example, consider the following table where “Name” is coded in one cell, followed by an empty cell and then the input box.

Name:

Input box

Linearity is the key, related information should be coded sequentially and in the correct order. In the above example, the screen reader would typically find the edit box and then read the cell that immediately precedes it, which is the blank cell. So someone using a screen reader would hear “blank, edit”.

Forms validation, error checking and calculation on the client-side using JavaScript or similar scripts, have the advantage of being both faster and more flexible, and there is no reason why they should not be used. However, you must also provide server-side equivalent functionality to support people who do not have script enabled browsers.

For more details on accessible scripting, please refer to the Accessible JavaScripts or JavaScript in Forms links at the bottom of this page.

Use an asterisk "*" to highlight information that has been filled out incorrectly or which is compulsory. Ensure that the "*" is grouped with the text label. Note that there is no reason why the "*" cannot be coloured, in red for example, to draw attention to it as, combining the symbol and colour means that this does not rely on colour alone.
Provide warnings if pages will time-out. If possible, provide a control to allow users to override the time limit if they need to. When the time-out function refreshes the page, make sure that a login facility and links to other areas of the site are made available. For more guidance on this, please refer to the section called "Time-outs, page refreshes and auto-redirects".
Dynamically updating content and dropdowns may not be accessible to everyone. If your form includes either of these techniques, provide an accessible alternative.

For further guidance, please refer to the link to Dynamic Content and Menus at the bottom of this page.

Placement text and initial values can be provided for fields as prompts. If you do so, you must ensure deletion of placeholder text and values as soon as the cursor focus moves to the field. It is important not to rely on placeholder text to convey the purpose on it’s own, a text label must also be provided.
Keyboard controls can help users navigate around your form. Provide ACCESSKEY and TABINDEX attributes for long or complex forms, especially if the form fields have been coded in the HTML in a different order from the one in which they appear on the page.

For details on how to do this, please follow the, " hidden navigation link provided under further information.

Using graphical buttons can be perfectly accessible, as long as meaningful ALT text is provided for buttons that use images. If the button is an image of text, the ALT attribute should simply use the same wording as is visible on the image. Otherwise the ALT should describe the purpose of the button. .

Testing tips

Instructions should be easy to read, providing clear headings, short sentences and be succinct. Text labels must appear to on the left of input and text fields, right of checkboxes and radio buttons. Ensure forms and content are tabbed through in a logical order and that the form makes sense when linearized.

Automatic testing tools - Automated tools can flag up pages with forms on, other methods must then be applied to ensure that the forms are accessible.
Accessibility toolbar – Doc Info - Page Information [new window]. Any FORM elements on the page will be listed near the end of the information displayed. To ensure that labels have been provided: . Structure - Fieldset/Labels. To ensure that there is a logical order through all form elements: Structure – Tab Order. OR Structure - Linearize.
Browser - Read pages and judge if they are clear. It would also be useful to submit forms to task driven user testing, to ensure that instructions are complete and understandable. . Scan the page visually to make sure that all form fields have appropriate labels.
Screen reader - Listen to:
a) the order of output.
b) the whole form to ensure that visible labels are read out correctly.

Further information

Hidden navigation – find out how to provide helpful additional keyboard navigation in your forms.

W3C WAI compliance

1.1 Provide a text equivalent for every non-text element (eg via "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (eg animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. Priority 1
10.2 Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. Priority 2
12.3 Divide large blocks of information into more manageable groups where natural and appropriate. Priority 2

For more information on techniques visit the Web Accessibility Initiative techniques page.

Other pages about accessible scripts and forms

Back to Design and build

For Web access centre updates email webaccess@rnib.org.uk

Content author: webaccess@rnib.org.uk

Last updated: 19/06/2009 12:54

Print Email