Home -> (Resources) ->
Manual evaluation -> Reference
Please also see my current work at
The Enabled Web.
Section 508 manual 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 structured 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. (The additional, separate layer of dynamic page behavior is not checked here.)
- 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
- FF/Illinois: Navigation -> Headings (this list
can also be used to navigate to any heading)
- 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 can be used to provide additional information
about an image; if used, it should not duplicate the alt-text.
- Tools:
- FF/developer: Images ->
Display Alt Attributes
- FF/developer: Images -> Disable Images -> All Images
- FF/developer: Information -> Display Title Attributes
- FF/Illinois: Navigation ->
Links (also shows Title attribute)
- FF/Illinois: Navigation -> Image Maps
- FF/Illinois: Text Equivalents -> Show Text Equivalents
- 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, many
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:
- Visual inspection
- 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 elements (for example, "display: none") may be
inaccessible to all users.
- Tools:
- FF/developer: CSS ->
Disable Styles -> All Styles
- FF/Illinois: Style ->
Disable CSS; Style -> Disable Tag Styling; Style -> Disable Table Layout. (Note that
these three steps provide more information that simply disabling all styles at once)
- IE/AIS: CSS -> Disable CSS
- 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)
- FF/Illinois: Navigation -> Data Tables
- 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:
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:
- 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:
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)
- FF/Illinois: Scripting -> Disable Scripting
(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
- FF/Illinois: Navigation -> Forms
- 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,
Fangs simulator,
FireVox page reader or
CLiCK, Speak talking browser extension
User validation procedure
