Section 508 Checklist

Web Accessibility Guidelines

Accessibility begins with good design. Inaccessibility is anything that prevents a person from obtaining needed information. By designing Web pages that follow the ten guidelines below, you will produce online information that is accessible to all users. The guidelines are based on recommendations from the World Wide Web Consortium (W3C) and the standards created by the Architectural and Transportation Barriers Compliance Board (Access Board) as part of Section 508 of the Rehabilitation Act of 1973.

The guidelines are first presented in a simple list. Each guideline is linked to additional information. Each one is categorized as being either "required" or "recommended".

Some items are followed by examples. The examples include instructions for HTML source code as well as for FrontPage, but other Web page authoring programs can accomplish the same result in different ways.

Once a Web page is developed, it needs to be tested for accessibility using a validator such as Bobby at www.cast.org/bobby/.

Number Guideline Description

Guideline 1 Create Web pages that are clear and simple, so they are more easily understood.

Guideline 2 Logically organize your page and use HTML to encode meaning rather than appearance -- use HTML tags for purpose they were created and use style sheets where appropriate.

Guideline 3 Provide equivalent alternatives to auditory and visual content, including images, graphics, animated graphics, image maps, video clips and audio clips or sounds, and to any other non-text elements, including applets, programmatic objects, and scripts.

Guideline 4 Provide clear and consistent navigation and links.

Guideline 5 Use color and background images judiciously.

Guideline 6 Create tables that work properly.

Guideline 7 Don't use moving, blinking, scrolling or automatically-updating objects, or ensure that these objects or pages may be paused or stopped.

Guideline 8 Ensure that forms provide device-independent access.

Guideline 9 Avoid using frames.

Guideline 10 Additional considerations, including using "text-only" pages and PDF files.

Create Web pages that are clear and simple, so they are more easily understood.

REQUIRED: Consistent page layout, recognizable graphics and easy-to- understand language benefit all users. Use the clearest and simplest language appropriate for a site's content and audience.

"Every word and phrase should have to fight for its life.

That means writing 'use' instead of 'utilize' which is identical in meaning, but has two more syllables."

--Crawford Kilian, "Effective Web Writing," Web Techniques, Feb 2001

REQUIRED: Clearly identify places where text or text equivalents change to a different language to facilitate pronunciation or interpretation of foreign text. Speech synthesizers and Braille devices can automatically switch to the new language if appropriate HTML markup is used.

RECOMMENDED: Expand abbreviations and acronyms the first time they occur to assist with interpretation.

Example:
OCM (Office of Communications and Marketing) recently approved Indiana University's Web Accessibility Guidelines.

‹‹ Back to Top

Logically organize your page and use HTML to encode meaning rather than appearance -- use HTML tags for purpose they were created and use style sheets where appropriate.
1. REQUIRED: Use HTML tags for the purpose they were created. For example, for headers use header tags <H1><H2>, etc., rather than font size changes, to note sections and subsections of your page.
  - Use style sheets rather than <blockquote></blockquote> or list tags to create indentation or margins. The <q></q> tag is used within a paragraph to quote a direct source. The <blockquote></blockquote> tag is used for a longer quote, which is "blocked" or indented from each side margin.
  - Use list tags only to create lists.
  - Use style sheets, not header tags, to create changes in font size.
  (See next recommendation 2C below for more information on using style sheets.)
2. REQUIRED: Documents must be readable without requiring associated style sheets. (See next recommendation for more information on using style sheets.)
  Turn off style sheets within your browser to test how your page will look.
  - In Netscape:
    1. Edit | Preferences | Advanced
    2. Uncheck "Enable style sheets." Click "OK"
  - In IE:
    1. Tools | Internet Options | General
    2. Click on "Accessibility" (bottom of page)
    3. Check "Ignore font styles specified on Web pages."
    4. Click "OK" and "OK" again.
3. RECOMMENDED: Style Sheets -- Use style sheets to control layout and presentation, but test the pages with various browsers to ensure that the content is accessible in browsers that don't support style sheets.
  Following is a helpful reference for using style sheets:
  Reference Web Site for CSS Master Compatibility Chart
  (http://www.webreview.com/style/css1/charts/mastergrid.shtml)
4. RECOMMENDED: Lists -- to make your lists more accessible, do the following:
  - Announce the occurrence of the list and announce the number of available choices before the list begins.
  - Label list items numerically if it is a sequential list; if not, use bullets.
  - Label sublist items alphabetically.
  The following list identifies three basic accessibility guidelines.
  1. Create Web pages that are clear and simple, so they are more easily understood.
  2. Logically organize your page and use HTML to encode meaning rather than appearance.
  3. Provide equivalent alternatives to auditory and visual content.
    1. All <img> tags must include an "alt" attribute.
    2. Use simple words to describe the function of structural elements rather than describing the appearance.
5. RECOMMENDED: Divide large blocks of information into more manageable groups where natural and appropriate. Use a "Table of Contents" at the top of your page (where appropriate) and provide "Back to Top" links at each section break.
‹‹ Back to Top
Provide equivalent alternatives to auditory and visual content, including images, graphics, animated graphics, image maps, video clips and audio clips or sounds, and to any other non-text elements, including applets, programmatic objects, and scripts.
When considering use of images, audio and video content, first ask yourself these questions: "What is the purpose of this visual content? How important is the visual content to the meaning of the page/site? How can I convey the information presented in the visual or auditory content for those who aren't able to see, read or hear it?"
If the visual content provides no clear advantage or meaning, consider omitting it. The benefit of the content should outweigh the inconvenience of additional download time. If the content provides a clear advantage, be sure to make it accessible using the following guidelines.
1. REQUIRED: All <IMG> tags must include an "alt" attribute, which contains a brief, interpretive text description for users who have images turned off, are using text-browsers or are using screen-readers.
  If no alternative text is provided, then text-browsers and screen readers will display/read [inline-image] as the description. Don't use alt=" " because screen readers may say "blank" instead of saying nothing at all. This may confuse the user. The "alt" attribute can also be used to provide a small amount of additional information.
  Example:
  The "alt" attribute in the following code is describing a graphic image which simply says, "What's New."
  <A HREF="/announce/"><img src="new.gif" width="30" height="14" alt="What's New at IU"></a>
  If you are using Microsoft FrontPage to create or edit your pages, you will need to explicitly insert the text alternative because you will not be prompted to do so. Select the image; right-click on the image and choose the "Picture Properties" option. Provide the description in the "alternative representations" text window.
2. REQUIRED: Use simple words to describe the function of graphical elements rather than describing the appearance.
  Use the word "bullet" to describe an image that precedes list items.
  <img src="green_ball.gif" alt="bullet" width="9" height="9">
  Use the words "page divider" or "separator" to describe an image which separates portions of your page.
  Use the words "spacer graphic" to describe images that provide space or "hold together" your page elements (e.g. shim.gif).
3. REQUIRED: Image maps must include "alt" attributes for all hyperlinks. Describe the graphic image used for the image map by providing an "alt" attribute with the <area> tag or provide a hyperlink for a text html page, which describes the graphic image map. To assist users who have difficulty with fine motor movements, design image maps that don't require extremely precise mouse positioning.
4. REQUIRED: Use client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
5. REQUIRED: If a server-side image map must be used, provide "redundant" text links for each active region of the image map.
6. REQUIRED: Provide a hyperlink to a text html page or provide an audio description of the important information of any video content. The Office of Adaptive Technology can provide information on how to create text description of visual images.
7. REQUIRED: For any time-based multimedia presentation (e.g. a movie), provide a synchronized equivalent. Using a product such as MAGpie (http://www.wgbh.org/wgbh/pages/ncam/webaccess/magindex.html), it is possible to produce a video clip that contains synchronized captions and descriptive video.
8. REQUIRED: When a Web page uses scripting languages to display content or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
9. REQUIRED: When a Web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that will function with assistive technology.
‹‹ Back to Top
Provide clear and consistent navigation and links.
1. REQUIRED: Use descriptive, concise hyperlink names. Hyperlinks should make sense when they are read one at a time or out of context. Rewriting the phrase or sentence surrounding the link is the best way to eliminate confusion. Most screen readers will pull out all of the links of a page, providing users with a way to navigate quickly. Just imagine trying to make sense out of a list of links in a screen reader like this:
2. REQUIRED: Provide a way that permits users to skip repetitive navigation links. The following information comes from the W3C:
  When links are grouped into logical sets (for example, in a navigation bar that appears on every page in a site) they should be marked up as a unit. Navigation bars are usually the first thing someone encounters on a page. For users with speech synthesizers, this means having to hear a number of links on every page before reaching the interesting content of a page. There are several ways to allow users to bypass groups of links (as users with vision do when they see the same set on each page):
  Include a link that allows users to skip over the set of navigation links.
  Provide a style sheet that allows users to hide the set of navigation links.
  Use the HTML 4.01 MAP element to group links, then identify the group with the "title" attribute.
  In the future, user agents may allow users to skip over elements such as navigation bars.
  End of W3C information.
3. RECOMMENDED: Provide sufficient space between links to assist users who have difficulty with fine motor movements. Providing space around, and separators between, links also makes it easier for sighted users to differentiate among the links. The pipe character ( | ) is a good alternative for separating consecutive links, and most screen readers have adapted to reading this as a break between navigational links.
  Example:
  [ Undergraduate Admissions | Graduate Admissions ]
4. RECOMMENDED: Avoid using hyper-linked images as the sole source for navigation. If you use an image, combine it with text that describes the hyperlink and include a text equivalent.
5. RECOMMENDED: Avoid automatically redirecting the user from one Web page address to another. Every time the user clicks the "Back" button in the browser menu bar, the browser returns to a page that bounces the user forward to the same page on which he is currently located. If you must use an immediate redirect, provide links to appropriate pages (including www.winona.edu) to help the user get out of the "redirect loop."
6. RECOMMENDED: Place navigation links and buttons in a consistent location throughout your site.
7. RECOMMENDED: Avoid using pop-up windows or causing a hyperlink to open in a new browser window, as this can be confusing to users who can't see that this has happened. If you are going to open a link within a new browser window, inform the user prior to the hyperlink.
‹‹ Back to Top
Use color and background images judiciously.
1. REQUIRED: Ensure that all information conveyed with color is understandable if viewed without color or if presented in an auditory manner.
  If color alone is used to convey information, people with certain visual impairments, people using text-only browsers or those using screen reading software will have difficulty discerning meaning. Don't use color as the only way to differentiate choices, demonstrate emphasis or indicate mandatory fields on a form.
2. REQUIRED: Background images must be light enough that they don't hinder readability or lessen the contrast between the text and the background.
3. RECOMMENDED: Provide sufficient contrast between background and text colors, so the text on the page is legible.
  Dark letters on a light background are easier to read than light letters on a dark background. In addition, light letters won't be legible when printed.
  The most common form of colorblindness is red-green, so this combination is especially troublesome.
‹‹ Back to Top
Create tables that work properly.
1. REQUIRED: For Web visitors using screen readers, tables will be read beginning with the cell at the upper-left-hand corner of the table. That cell will be read in its entirety, and then the next cell to the right will be read. Be sure your information makes sense when read in this order. Otherwise, provide an alternative equivalent (e.g. providing the information in a non-tabular format).
  To get a better understanding of how a screen reader would read a table, run a piece of paper down the page and read your table line by line.
2. REQUIRED: Use the <TH> tag to identify a header or title for a table column or row, and use the <TD> tag to identify data in each table cell that corresponds to the header or title.
  Example of guideline 6B - using <TH> and <TD> tags
3. REQUIRED: For data tables that have two or more logical views of row or column headers, use markup to associate data cells and header cells to describe more complex relationships among data.
  More information from the W3C on using markup to associate data and header cells.
4. RECOMMENDED: If you use an absolute width for your table, be sure it will fully display on a browser set to 640x480 resolution (try 580 pixels). If your table extends beyond the browser window, a screen reader may only read to the edge of the window, ignoring all text beyond the window.
5. RECOMMENDED: Provide a summary via the "summary" attribute within the table tag.
‹‹ Back to Top
Don't use moving, blinking, scrolling or automatically-updating objects, or ensure that these objects or pages may be paused or stopped and/or provide equivalent information in an alternative accessible format.

Screen readers are unable to read moving text. Some people with cognitive or visual disabilities are unable to read moving text quickly enough or at all. Movement can also cause such a distraction that the rest of the page becomes unreadable.
1. REQUIRED: Don't use the <BLINK> or <MARQUEE> elements.
2. REQUIRED: Don't cause the screen to flicker. A flickering or flashing screen may cause seizures in users with photosensitive epilepsy. Seizures can be triggered by flickering or flashing in the 4 to 59 flashes per second (Hertz) range with a peak sensitivity at 20 flashes per second as well as quick changes from dark to light (like strobe lights).
‹‹ Back to Top
Ensure that forms provide device-independent access.

Device-independent access means that the user may interact with the user agent or document with a preferred input (or output) device, such as a mouse, keyboard, voice or head wand. If a form control can only be activated with a mouse or other pointing device, someone who is using the page without sight, with voice input, or with only a keyboard will not be able to use the form.
1. REQUIRED: When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements and functionality required for completion and submission of the form, including all directions and cues.
2. REQUIRED: Provide a phone number the Web visitor can call to verbally supply the requested information. An e-mail address should also be included.
3. RECOMMENDED: Preface each form element with a descriptive name followed by a colon. The Microsoft Active Accessibility (MSAA) software calls each form element by the word prior to and on the same line as the form element.
  
  Example:
  Name: <INPUT TYPE="text">
4. RECOMMENDED: Keep the form element and its description on the same line in the form.
‹‹ Back to Top
Avoid using frames.

Unless you have a compelling reason to use frames, avoid them altogether. If you must use frames,
1. REQUIRED: Provide a non-frames alternative that includes navigation.
2. REQUIRED: Title each frame to facilitate frame identification and navigation.
3. RECOMMENDED: Give your frames meaningful names and titles to assist with identification and navigation. Describe the purpose of the frames and how the frames relate to each other if it is not obvious by the frame titles alone.
4. RECOMMENDED: Don�t use frames that show only a portion of the content of that frame. Screen readers won't read information that is outside of the frame.
‹‹ Back to Top
Additional considerations, including using "text-only" pages and PDF files.
1. REQUIRED: A text-only alternative page should be used only when compliance cannot be accomplished in any other way. If used, the content of the text-only page must be updated at the same time as its graphical counterpart.
  
  Work to produce accessible Web pages. Having two versions of the same page doubles your maintenance time.
2. REQUIRED: When providing a PDF (portable document format by Adobe), test to see whether the file can be read with screen reading software. If it can't, provide a text file equivalent either in HTML or text format. Adobe currently provides an accessibility tool that you can use to convert a PDF file to an HTML or text format.
3. RECOMMENDED: When providing files for downloading, provide a non-proprietary file format (.txt) option
4. RECOMMENDED: Use a text-only browser such as Lynx to test how your pages will look/read using text only. Using a telnet utility, log onto discover.wright.edu. At the prompt, type the word "lynx." Choose "G" for "Go" and at the prompt, type in the URL for the page you wish to check.
5. RECOMMENDED: Use an accessibility validator such as Bobby to test your pages.

‹‹ Back to Top