Designing Accessible Web Forms

Why are forms such tricky business? Perhaps because there are lots of very unforgiving pieces of code involved. It might have to do with the troublesome process of creating an interaction between your form and another computer-based entity, such as another form, or a database. And of course, the trickiest interaction of all takes place between your form and a human being.

But forms are also a great opportunity to improve accessibility because they are where you find out you have a problem. If you give users an article to read and you never hear from them, you might assume that they got the information they needed, and everything was fine. But when a user submits a form with crazy input in it—why do these people put the zip code in the city field?—an accessibility alarm should sound.

Logical Layouts

Forms need to be designed in a logical, consistent way. Make sure the question or description for each input field (a text box, checkbox, or select menu, for example) is on the same line as the input field itself.

Place the label consistently on the same side of the input field, and be sure to explicitly tell the user which bits of information are required. Don’t be subtle! Many web designers rely on color or bold text alone to indicate which items are required fields. Obviously, this technique is of little help to a user who is blind or visually impaired.

We recommend actually making the word Required part of the label for each mandatory field. This practice will benefit users who have low vision, who are color-blind, or who are accessing the site with a screen reader. It is also helpful to users with cognitive disabilities. In general, being consistent and logical in form design will help all users.

Labeling Form Controls

Use the “Label” Tag for Form Controls

Especially for users who access your site using screen readers, it can be extremely difficult or impossible to know what is required in input fields in forms. A user moving through an incorrectly marked up form may hear no more than “Edit edit edit radio button not checked radio button not checked Submit button.”

To make the form usable, explicitly label each control by enclosing the text associated with it in a <label for=””> tag. Then, add an ID attribute to the input field and make both the ID and FOR equal to the same value. Note: ID values must be unique. You cannot give multiple inputs in a form the same ID value.

Avoid Radio Buttons

Radio buttons are not supported consistently by all versions of browsers, screen readers, and combinations. A correctly labeled and tagged set of radio buttons is a very difficult control for users of screen-reading technology. If a “choose only one” situation is called for, a select menu is preferable.

If you must use radio buttons, remember to label them with the “Label for” tag. When radio buttons are used, each radio button in the group has the shared name, but a unique ID. Each radio button in the group has a unique label, as well.

Select Menus

Label Select Menus Inside and Out

The default item in a select menu (also known as a “pulldown menu” or “combo box”) should clearly define the purpose of the menu. For example, “Select Age Range” is preferable to “18-25.” Many screen readers and browsers fail to connect the label with the menu, so users may never see the label.

Keyboard Accessibility

Many users do not use a mouse, but instead use the keyboard to move through the form. One of the main barriers to keyboard accessibility can be the use of client-side scripts, small sections of programming code that run in the user’s browser instead of on the web site’s computer. Be cautious about using client-side scripts to change the browser’s focus, manipulate the data, or submit forms. These techniques can make a form impossible to use with the keyboard alone.

Make sure select menus work with the keyboard as well as with the mouse. Some menus are configured, usually with a client-side script, to take an action as soon as the user has selected an item. Since the keyboard user must pass through the first four items to select the fifth, this select menu does not work for them. The screen-reader-user has reading and navigating tied together in one action, so this user is not only yanked away to the wrong page, he or she does not know what it will be.

Instead, provide a normal submit button that the user can select at leisure, after reviewing all the menu items.

Checkboxes

Checkboxes are a simple control and should be labeled as described above. But they are worth handling with special caution because they often appear after explanatory text or a long question. If the checkboxes’ labels include only the answers and not the original question, the user will miss important information.

A designer using common sense might label a choose-all-that-apply question in a technically correct manner, but might fail to make them usable to test-takers.

Solution: Use the Fieldset Tag

A better approach to the checkbox problem is to use a “fieldset” tag, and then create a “legend” for the fieldset. A fieldset tag allows the designer to treat several different input fields as a group, with a shared description.

Testing Your Form

It is nearly impossible to know whether you’ve marked up your form correctly without testing it with a screen reader. Use more than one screen reader. They can sometimes make good guesses about bad markup and mask a problem.

Read the form by tabbing from one input field to another without trying to fill out the form. Fix any errors you find.

Now test the form by entering the screen reader’s “forms mode” and attempting to fill out the form. You may find quite different results. Fix any additional errors you discover.

The Bottom Line

In summary, if you lay out your forms logically and consistently, make proper use of labels, and avoid client-side scripts and radio buttons, your web forms will be much more accessible to users who are visually impaired.

For more information about creating accessible web sites, explore the Creating Accessible Websites area of the AFB site, or visit the World Wide Web Consortium’s Web Content Accessibility Guidelines at http://www.w3.org/TR/WCAG20/.

Tips and Tricks to Improve Web Accessibility

1. Relative Font Sizes

Use relative font sizes expressed in percentages or ems, rather than absolute font sizes expressed in points or pixels. This practice allows users to make the text larger or smaller as desired—an important feature for users with low vision.

2. Provide Alternative Text for Images

It is absolutely necessary to provide text equivalents for all meaningful graphics. If the graphic includes text, be sure that the alternative text (often referred to as an “alt tag”) supplies all of the words.

Example:
<img src=”graphic.gif” alt=”Acme – supplying widgets since 1945″ width=”50″ height=”20″>

That said, providing “alt” text for spacers or placeholding graphics subjects the speech user to meaningless information. Spacers or graphics used only for positioning should be labeled with alt=” ” (quote, space, quote). Note that you should never completely omit the alt tag, even for placeholding graphics. This omission subjects the speech user to hearing the file name of the image.

If you are in doubt as to whether or not to describe an image with an alt tag, do it.

3. Name Links Carefully

Users often move through a page by tabbing from link to link. Never use “Click here” or “Learn More” as the text for your links. “Download New Version” is self-explanatory.

4. Explicitly State Information

Do not use indentation or color alone, for example, to convey meaning.

Example:

Indicating required fields in a form by making them bold is bad.
Indicating required fields by using a phrase such as “required” is good.

5. Label Forms Properly

Create a predictable, consistent interface for your users. For example, make sure the question or description is consistently on the same side of its control. Ideally, place the question or label on the same line as the input field itself.

Enclose the label associated with an input field in a <label for=””> tag, or wrap it in a fieldset.

6. Provide Skip Links

Skip links allow the speech software or braille user to bypass information that is repeated on every page, such as navigation bars. Speech and braille users generally read the page from top to bottom and consequently are subjected to repeated information before reaching the heart of the page. Skip links allow these users to jump past the repetitive navigation links to get to the main content on the page.

To implement skip links, place a link before the repeated information as follows:

<a href=”#content”><img src=”empty.gif” height=”15″ border=”0″ alt=”Skip Main Navigation” width=”5″></a>

and place an anchor at the beginning of unique copy:

<a name=”content”></a>

The image can be transparent so that the visual display is not affected, but speech and braille users can hear the alt tag reading “skip main navigation”.

It is also possible to use a text link that literally says <a href=”#content”>skip main navigation</a>, if you prefer. We do not recommend using an “invisible” text link, like a single space or underscore. That technique relies on the link’s title to provide accessibility, and not all screen readers provide the link title to the user.

Creating an ADA-compliant website

Title III of the Americans with Disabilities Act (ADA) requires that businesses and nonprofit services providers make accessibility accommodations to enable the disabled public to access the same services as clients who are not disabled. This includes electronic media and websites. While the ADA applies to businesses with 15 or more employees, even smaller businesses can benefit from ensuring that their websites are ADA compliant. Doing so opens your company up to more potential clients and limits liability. Web developers should include ADA compliant features in the original site and application plans.

This is particularly important when working for a government agency or government contractor, as these organizations must follow web accessibility guidelines under Section 508 of the Workforce Rehabilitation Act of 1973. Although ADA and Section 508 compliance are different, the published checklist for Section 508 compliance offers insight into ways to make websites accessible for people with disabilities, and thereby work toward ADA compliance.

To check your website for accessibility, you can use the accessibility checklist published by the U.S. Department of Health and Human Services (1194.22 Web-based intranet and internet information and applications):

  • Every image, video file, audio file, plug-in, etc. has an alt tag
  • Complex graphics are accompanied by detailed text descriptions
  • The alt descriptions describe the purpose of the objects
  • If an image is also used as a link, make sure the alt tag describes the graphic and the link destination
  • Decorative graphics with no other function have empty alt descriptions (alt= “”)
  • Add captions to videos
  • Add audio descriptions
  • Create text transcript
  • Create a link to the video rather than embedding it into web pages
  • Add a link to the media player download
  • Add an additional link to the text transcript
  • The page should provide alternative links to the Image Map
  • The <area> tags must contain an alt attribute
  • Data tables have the column and row headers appropriately identified (using the <th> tag)
  • Tables used strictly for layout purposes do NOT have header rows or columns
  • Table cells are associated with the appropriate headers (e.g. with the id, headers, scope and/or axis HTML attributes)
  • Make sure the page does not contain repeatedly flashing images
  • Check to make sure the page does not contain a strobe effect
  • A link is provided to a disability-accessible page where the plug-in can be downloaded
  • All Java applets, scripts and plug-ins (including Acrobat PDF files and PowerPoint files, etc.) and the content within them are accessible to assistive technologies, or else an alternative means of accessing equivalent content is provided
  • When form controls are text input fields use the LABEL element
  • When text is not available, use the title attribute
  • Include any special instructions within field labels
  • Make sure that form fields are in a logical tab order
  • Include a ‘Skip Navigation’ button to help those using text readers

(Courtesy U.S. Department of Health and Human Services)

If the site meets all these criteria, it is likely accessible to people with disabilities. The best test is to obtain feedback on the site’s ease of use from people who are blind, deaf, and have mobility disabilities, then address their feedback with site improvements.

When collecting feedback, ask users what type of adaptive technologies (AT) they use. This will allow you to cater your website to your particular clientele, and will help you appoint resources toward the best compliance options. Navigating the Internet is particularly challenging for people with limited or no vision. Many blind people use specialized web browsers and software that works with standard web browsers, like Firefox, that have features that enable users to maximize their Internet use and experience. This screen reading software reads the HTML code for websites and gives the user a verbal translation of what is on screen.

Web developers need to keep this in mind when creating websites. The best screen readers use naturalized voices and alter tone and inflection based on HTML tags, so choose layout elements carefully. It is also important to keep in mind that navigation is significantly slower when using a screen reader than it is for sighted people. Sighted people don’t have to wait for the reader to get to the link we want- we spot links quickly and are able to navigate to our sought items, often without having to do any reading at all. Minimizing graphics also helps shorten reading times and speed navigation for disabled users.

Don’t wait for user feedback to discover the gaps in your website’s accessibility. Conducting your own trial run will tell you where the site has too many graphics, and where HTML tags don’t convey information accurately. It’s wise to do trial runs with as many of the most popular screen readers available:

Development tools and tutorials exist to help web designers meet compliance standards and go beyond to offer disabled users an enjoyable experience (and keep them coming back). Check out the following for more information:

Then make your job easier with these web accessibility development tools:

You probably won’t have to check your site with all of the available evaluation tools out there, but it is a good idea to do so for the most common web browsers. Just as accessibility software makes it easier for people with disabilities to navigate the Internet, these tools make it easier for developers to ensure accessibility from the start. When you think you’ve mastered it, go through the Section 508 compliance checklist to ensure you’ve met every goal.