Accessible Technology Initiative (ATI)

Section 508 manual website evaluation reference

Many of the steps in the accompanying manual evaluation might be accomplished with nothing more than a review of the page as displayed in the browser plus a careful examination of the HTML source code. However, most will be assisted by using some combination of the developer tools listed below. For online sources of these tools and instructions for download, installation and use, please see the evaluation tools page.

Many well-meaning developers assume that "if a blind person can use the page, it's accessible," or "if it look OK in Lynx (the original text-only browser), it's accessible." Unfortunately, accessibility is not as simple as that. Users with low vision (of which there are many forms), users with cognitive disabilities, users with degraded motor skills, deaf users, and many other groups need quite different accommodations than do the blind. Please remember these groups as you are evaluating each checkpoint.

Syntax validation

  • Why this is important: Contemporary, maintainable, accessible web design is based on complete separation of content (HTML/XHTML) from presentation (CSS) with both conforming to W3C standards; valid code contributes to accurate presentation by both standard browsers and assistive technologies.
  • Tools:
    • FF/developer: Tools -> Validate HTML
    • FF/developer: Tools -> Validate CSS
    • IE/AIS: Validate -> W3C HTML Validator -> Validate HTML
    • IE/AIS: Validate -> W3C CSS Validator -> Validate CSS.
  • References:

Syntax validation procedure

Semantic validation

  • Why this is important: Page elements that function as links (including text, images, and buttons) should be recognizable and usable by sighted viewers and assistive technology. All visitors are helped by logically-organized page content that uses section headings and sub-headings in their proper order; visitors using assistive technology can use the headings for easy navigation between sections of the page.
  • Tools:
    • FF/developer: Information -> Display Link Details
    • FF/developer: Information -> View Document Outline
    • IE/AIS: Structure -> Headings
  • References:

Semantic validation procedure

Checkpoint A, text equivalents

  • Why this is important: Assistive technologies such as screen readers can't read images; neither can search engines. Some sighted visitors might have images disabled for various reasons, or images might fail to load over a network. If alt-text is not given for images used as links, screen readers will read the whole URL instead, which is horribly confusing for listeners! The title= attribute (best practice) is used in Firefox for mouseover (alt= is used in IE); many low-vision users benefit from having this available.
  • Tools:
    • FF/developer: Images -> Display Alt Attributes
    • FF/developer: Images -> Disable Images -> All Images
    • FF/developer: Information -> Display Title Attributes
    • FF/Illinois: Navigation -> Links (shows Title attribute!)
    • FF/Illinois: Navigation -> Image Maps
    • IE/AIS: Images -> Toggle Image/Alt
    • IE/AIS: Images -> Show Image Maps
    • IE/AIS: Doc Info -> Show Titles
  • References:

Checkpoint A validation procedure

Checkpoint B, multimedia equivalents

  • Why this is important: All of the problems addressed in checkpoint A are compounded by multimedia presentation, where a visual equivalent of audio content is needed as well as an audio equivalent of visual content. In addition, most assistive technologies are unlikely to have plugins that can deal with multimedia formats.
  • Tools:
    • Visual and audio inspection
  • References:

Checkpoint B validation procedure

Checkpoint C, color

  • Why this is important: Visitors both with full vision and with various forms of color blindness require sufficient contrast to read text easily. If images are used as background, contrast may change when they are unavailable. Color-blind users may be unable to distinguish information conveyed by color without alternate coding of that information; blind users obviously cannot use color information at all.
  • Tools:
    • Colour Contrast Analyser: check all foreground/background combinations for sufficient contrast for sighted and color-blind users
    • Colour Contrast Analyser: check the page in each simulation of visual diabilities
    • FF/developer: Images -> Disable Images -> All Images
  • References:

Checkpoint C validation procedure

Checkpoint D, styles

  • Why this is important: Many low vision visitors will disable the page author's styles, and may substitute a custom style sheet of their own. If styles are used to substitute for semantic markup, low-vision and text-only readers will be unable to understand the structure of the page. (Example: large bold text used instead of a heading.) Elements that are hidden from sighted users will also be hidden from low-vision users who may need to see them; badly hidden element may be inaccessible to all users.
  • Tools:
  • References:

Checkpoint D validation procedure

Checkpoint E, server-side image maps

  • Why this is important: This checkpoint was written at a time when server-side image maps were already becoming obsolete.
  • Tools:
    • Replace server-side image maps.

Checkpoint E validation procedure

Checkpoint F, client-side image maps

  • Why this is important: Image maps are designed for fully-sighted readers who can also use a mouse. Each clickable area must be identified with its link target, and must be reachable via its tab order, just like all other links. Frequently, an alternate means of selection may prove easiest to use for all visitors. (Example: a drop-down list of states in addition to an image map of the country.)
  • Tools:

Checkpoint F validation procedure

Checkpoint G, simple tables

  • Why this is important: Simple data tables are those consisting of only one column header, and possibly one row header, for each data cell. Unless the HTML code explicitly associates each data cell with its column (and row, if applicable) header, visitors using text readers will hear only a string of unintelligible data values. Technically, this is done with the <th scope= ...> element. Text-only visitors also might need assistance in understanding the purpose of the table, which may be provided to them with the summary attribute of the <table> element. On the other hand, text-only visitors should never have to hear summaries such as "this table is for layout only."
  • Tools:
    • FF/developer: Information -> Display Table Information
    • FF/developer: Outline -> Tables -> Table Cells
    • FF/developer: View Source -> View Source (nice color-coded listing)
    • IE/AIS: Structure -> Show Table Headers
    • IE/AIS: Structure -> Simple Data Table (shows layout tables also)
    • IE 6 menu: View -> Source
    • IE 7 menu: Page -> View Source
  • References:

Checkpoint G validation procedure

Checkpoint H, complex tables

  • Why this is important: Complex data tables are those in which there is more than one level of header for any column or row. All of the simple table information also applies to these. For text readers to work properly on multiple levels of headings, id= attributes must be added to the <th> elements, and matching headers= attributes to each data cell. Additional markup such as the <thead> element can be used to further clarify the table structure.
  • Tools:
    • Tools listed under checkpoint G above
    • IE/AIS: Structure -> Complex Data Table
  • References:
    • See checkpoint G above

Checkpoint H validation procedure

Checkpoint I, frames

  • Why this is important: Untitled frames cannot be navigated by assistive technology, leaving some visitors unable to reach major portions of the page content. Some assistive technologies might not support frames at all, and it is almost impossible to provide truly equivalent content with the <noframes> element. For these reasons and many others, the use of frames is deprecated by the W3C in favor of element positioning with style sheets.
  • Tools:

Checkpoint I validation procedure

Checkpoint J, flicker

  • Why this is important: At worst, flickering and flashing page elements can cause epileptic seizures in some viewers. They are also disruptive to many readers with cognitive disabilities or low vision. At best, they have become an irritant to nearly everyone. Unfortunately, user agents still do not provide easy-to-use, comprehensive solutions to these problems.
  • Tools:
    • Visual inspection
  • References:
    • The glossary of the new WCAG 2.0 Guidelines gives precise definitions of the terms "blink," "general flash threshold," and "red flash threshold."

Checkpoint J validation procedure

Checkpoint K, text only

  • Why this is important: This checkpoint was written before it became truly feasible to write a single version of a web page that is as accessible to disabled users as it is to the majority. The limitations of text-only pages were well known even at that time, though: they include the difficulty and cost of maintenance and the difficulty of insuring that content is truly equal in different versions of the page. Modern development standards have rendered the text-only page obsolete.
  • Tools:
    • Visual inspection

Checkpoint K validation procedure

Checkpoint L, scripts

  • Why this is important: Many users of assistive technology will not have scripting available; even users of standard browsers may have scripting disabled for security or other reasons. Keyboard-only users will not be able to access functionality that is provided only with mouse-triggered events. The now obsolete "<noscript>" alternative is almost never able to provide truly equivalent content and functionality.
  • Tools:
    • Visual, functional, and code inspection
    • FF/developer: Disable -> Disable JavaScript -> All JavaScript (then re-load page)
    • IE/AIS: IE Options -> Toggle JavaScript (then re-load page)
  • References:

Checkpoint L validation procedure

Checkpoint M, applets and plugins

  • Why this is important: This checkpoint has become substantially more complicated to evaluate since it was written. There are two problems here. The first, "applets," can be thought of as true computer applications running within a browser; for example, Java or ActiveX controls—these will have to meet the separate Section 508 standards for all computer software. The second, "plug-ins," could mean anything from Flash to Quick-time to PDF or even Word. Most browsers now provide built-in rendering for many of these formats, but many assistive technologies probably won't. Equivalent content will have to be provided for a large range of disabilities; for example, closed captioning of video and transcripts of audio—and formats such as PDF will have to be coded with current accessibility techniques.
  • Tools:
    • Visual, audio, and functional inspection depending on content.
  • References:
    • Web Accessibility, Chapter 11, "Accessible Flash" and Chapter 12, "PDF Accessibility"
    • Other references depending on application or format

Checkpoint M validation procedure

Checkpoint N, forms

  • Why this is important: Visitors using assistive technology need to access form controls independently of how they are presented on the screen. They also need to receive all of the cues that normal browsers provide—for example, which fields are mandatory and what, if any, errors have been made in completing the form. Proper semantic markup (XHTML) helps assistive technology to present form information and controls accessibly.
  • Tools:
    • Visual, functional, and code inspection
    • Jaws page reader or Fangs simulator.
  • References:

Checkpoint N validation procedure

Checkpoint O, skip links

  • Why this is important: This may be the most misunderstood and poorly implemented of all Section 508 checkpoints. Conventional wisdom is to hide a "skip" link from sighted viewers, often with an awkward and outdated single-pixel .gif image. Yet low-vision users may benefit from a visible way to bypass repetitive links, and fully-sighted viewers are not bothered in the least by its presence. Worse, pages might contain multiple groups of repetitive links, which a user might want to "skip" in whole or only in part. Since assistive technologies now support navigation by headings and lists, these constructs can be used to organize links beneficially for all users.
  • Tools:
  • References:

Checkpoint O validation procedure

Checkpoint P, timed response

  • Why this is important: Users may have a variety of difficulties when a timed response is required from a Web form. In education, one possible reason requiring such a response would be in an examination, where it would be impractical to allow all students to request more time, as called for in the checkpoint. Other accommodations, such as a customized version of the test or a special testing center, may have to be provided in this case.
  • Tools:
    • Visual and functional inspection

Checkpoint P validation procedure

User validation

  • Why this is important: Users with mildly low vision or some cognitive disabilities will benefit from text that is simply resized in a standard browser. Text that is styled to prevent this, or page layout that requires horizontal scrolling for large text, will be a barrier to these users. Even after all checkpoints appear to have been met, practical use by persons with actual disabilities, using their normal assistive technology or accommodations, may discover additional barriers that need to be fized.
  • Tools:
    • FF menu: View -> Text Size -> Increase or Decrease (or Ctrl-+ and Ctrl--)
    • IE 6 menu: View -> Text Size -> Larger, etc.
    • IE 7 menu: Page -> Text Size -> Larger, etc. (not Ctrl-+, which zooms whole page)
    • Low vision stylesheet
    • Jaws page reader or Fangs simulator.

User validation procedure

Copyright © 2007, by Tom Jewett, jewett@csulb.edu. Links to this site are welcome and encouraged. Individual copies may be printed for non-commercial classroom or personal use; however, this material may not be reposted to other web sites or newsgroups, or included in any printed or electronic publication, whether modified or not, without specific permission from the author.