Basic Web Accessibility Tutorial: Design and Development

Version 1.0, October 14, 2009

Contents

What is covered in this tutorial?

This is part 2 of a 3 part tutorial. Here is a short description of each part.

Definitions of terms used in this tutorial

Accessibility
The degree to which a device, service, or environment can be used by as many people as possible. Web accessibility means that people with disabilities can perceive, understand, navigate, interact with, and contribute to the Web.
Web content
Any Web page or Web application that is displayed in a Web browser. This is normally HTML content, but might also include other non-HTML elements, such as Java applets or multimedia players.
Accessible Web content
Web content that has been designed and created to comply with accessibility guidelines, with the goal of enabling the largest possible audience to use the content, regardless of disability or method of access.

How do I make my Web page accessible?

There are many things we can and should do to make our Web pages accessible.

The Web content accessibility requirements listed here are based on Texas state law (Texas Administrative Code, Chapter 206) and Federal law (Section 508 of the Rehabilitation Act). In some cases, the Worldwide Web Consortium (W3C) Web Content Accessibility Guidelines (WCAG 2.0) are used to clarify the requirements.

Designing for easier comprehension

The easiest rule to remember is that small and simple is easier to understand than  large and complicated. It is very difficult to provide specific rules for the size and layout of a page, but keep the "smaller, simpler" rule in mind when planning the design of each page in your Web content.

The following sections describe design and coding considerations for making your Web content easier to view/access and understand, as well as tools and techniques for testing the accessibility of your pages.

Default contrast

When designing your page, be sure there is sufficient contrast between the text and the background.

Text and paragraphs

Headings

Images

Flashing, Blinking, and Repetitive Movement

Be very careful when adding elements, either text or images, that flash, blink, or contain repetitive movements. These elements can cause a severe distraction, and can in some cases cause seizures. It is best to avoid using these elements, if possible.

If you decide you must include elements that blink, flash, or that provide repetitive movement, use the following guidelines:

If you have trouble counting the number of blinks in one second, you can try these steps.

  1. Count the number of flashes, blinks, or movements that occur in 10 seconds.
  2. Divide that number by 10 to determine the flash rate.
  3. If the result is greater than 3, you must either reduce the rate of flashing, or remove the element from the page.

Notes:

Multimedia (Audio and Video)

A text equivalent is needed for both audio and video.

Use of color and text decorations

Style Sheets

Cascading style sheets (CSS) can be used to manage much of the look and feel of a site. CSS contains instructions determining font styles, colors, and page layout, or placement of content on the page. The use of style sheets is strongly encouraged.

However, there are people who may be using browsers that do not fully support style sheets, and other people may override your style sheets with their own. The most common reason for overriding style sheets is to set a preferred high contrast or large font scheme. To ensure that those people can use your Web content, you must verify that your Web content can be successfully viewed and used even when your style sheets are disabled by the browser.

Data tables

A data table is a grid that contains a set of related information in row and column format. A data table contains column and/or row headers.

Visually, data tables are easy to understand because a sighted user can scan up to the top of the column or to the beginning of the row to read the column and row headers for any data cell in the table. For those users who cannot see, it is not so simple. If I use a screen reader to navigate from one data cell to another, I depend on the screen reader to announce the column headers as I change columns, or to announce the row headers as I change rows.

You, as the page author, must include table header tags (<th>) to identify the row and column headings in your table. A complete description of markup for accessible tables is beyond the scope of this tutorial, but here are some basic tips.

Include the scope attribute to tell the screen reader whether this is a row or column header. For example:

For more complex tables, multiple column headers or multiple row headers might apply to a single data cell.  In this case, you will need to use id and headers attributes to fully inform the screen reader which headings apply to each data cell.  However, keep in mind that people who use screen readers and people who have cognitive issues will find it more difficult to understand a complex table.  If you break a complex table into two or more simpler tables, it will often help everyone.

More notes on tables:

Designing for easier navigation

The following sections describe design, coding, and test considerations for making your Web content easier to navigate using the keyboard and with a screen reader.

Skip links

If the main page content is not the first thing a user encounters at the top of the page, or if there are blocks of repeated information on multiple pages, provide "skip links" to allow keyboard users to jump directly to the main page content. For example, many pages display a banner across the top of the page that contains a logo, links, or maybe a search field. There is often a section of site navigation links along the left side of the page. Provide links to skip past these sections, to enable keyboard or screen reader users to move to the more important content on your page.

Here are some guidelines for skip links.

Caution:

Text Links

Use meaningful link text for all hyperlinks.

Image links and image maps

Image links and image maps are a combination of images and links.

Because images and links are both used, the accessibility rules for both images and links apply. See the Images section for general rules on alt text for images.

Redundant Image Exception:

If an image is placed next to a text link, and the image links to the same target as the text link, use null alt text for the image. When using a screen reader, I do not need to hear the link target twice; once is sufficient. Take this example:

Section A Section A

Consider what will happen if the alt text for the image says "Section A". When announcing this section, the screen reader will say "Section A Section A", once for the image and another time when reading the text. Setting the image alt text to null will eliminate this duplicate announcement.

When coding this example, you must decide whether to make both the image and the text link to Section A, or just make the text link to section A.

Here are two acceptable ways to code the above example.

First, here is an example of making both the image and the text to link to the destination (to be 'clickable'):

<a href="#link-to-sectiona">
<img src="images/lettera.jpg" alt="" ... />
Section A
</a>

Second, here is an example of making only the text link to the destination. The image is not part of the link:

<img src="images/lettera.jpg" alt="" ... />
<a href="#link-to-sectiona">
Section A
</a>

Notice that in both examples, the image alt text is set to null, to prevent the screen reader from announcing redundant information.

Frames

Some pages use HTML frames to divide the Web page into separate scrollable areas. The contents of each frame are defined in separate Web page files. Be sure to identify the content found in each frame as follows.

Designing for easier interaction

The following sections describe design, coding, and test considerations for making your Web content easier to use when the content requires some sort of user interaction.

Linked documents or other non-HTML content.

If you link to PDF documents, Word documents, or any other content that cannot be displayed directly by the Web browser, be sure to provide a link to a downloadable application that will let me view the document or other content.

Important note about linked documents

If you link files from your Web site, be sure you know who your audience is. If you are publishing files for use by employees on the internal DARSnet site, for example, you know that employees have access to Adobe Reader and to Microsoft Office applications, so publishing PDF documents, Word documents or PowerPoint presentations is okay; DARS employees have the necessary viewers or applications to open these types of documents.

However, if you are publishing files to the internet, you cannot be sure that your audience has access to Microsoft Word or the other Office applications. Even though Microsoft does provide free downloadable viewer applications for Word and other document formats, those viewers may not be completely accessible and may not be compatible with the user's operating system..

Also, be aware that PDF, Word, and other Office applications have their own set of accessibility challenges. If you link to those types of files, it is your responsibility to verify that the information in those files is accessible. If possible, the best choice is to always publish your information as Web content, using HTML. In general, that is the most accessible cross-platform option available.

Forms

If you use form elements, like radio buttons, checkboxes, or text input fields, be sure to use <label for="…"> tags to associate text labels with each of the form elements.

Scripted elements

A scripted element includes any element where program code is used to modify the look of or provide a function that is beyond a simple HTML page element. It can vary from a simple JavaScript to a complex Web 2.0 widget.

 It is beyond the scope of this tutorial to describe how to make all scripted elements accessible, but here are some general rules:

Session timers

If there is a session timeout requiring that a task be completed in a specific amount of time, use the following guidelines.

Applets, multimedia viewers and players

If you include a Java applet, a multimedia viewer, or any other non-HTML content that requires user interaction, you must verify that the applet or content conforms to all Section 508 accessibility requirements for software applications.

The details of this requirement are beyond the scope of this tutorial, but here are some basic things you must verify:

What next?

This tutorial covered design and development issues related to Web accessibility issues. For coding examples of many of these concepts, proceed to the next portion of this tutorial: Basic Web Accessibility Tutorial: Examples.

More information

Related DARS tutorials

General Web page coding resources

General Web accessibility information

Web accessibility test tools