|
Automated evaluation tools only check things that can be evaluated
by a computer. These definitely do not include the human factors
that are contained here. Even looking at human factors cannot
guarantee accessibility for every possible user, but following this procedure
will certainly represent a good-faith effort to make a page or site as
accessibile as possible today.
Checkpoint A, text equivalents
A text equivalent for every non-text element shall be provided (e.g.,
via "alt", "longdesc", or in element content).
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.
- Must repair: Do images that convey content have equivalent alt-text?
(fix if "no")
- Internet Explorer /AIS: Images -> Toggle Image/Alt
- Must repair: Do purely decorative images have empty alt-text
(alt="")? (fix if "no")
- Internet Explorer /AIS: Images -> Toggle Image/Alt
- Must repair: Does alternate text make sense in the context
of the page as spoken? (fix if "no")
- Internet Explorer /AIS: Images -> Toggle Image/Alt
- Must repair: Do images that convey complex content
have longdesc attributes or equivalent text content elsewhere
on the page? (fix if "no").
- Internet Explorer /AIS: Images
-> Toggle Image/Alt
- Must repair: Does text content contained in images disappear
when images are not available? (fix if "yes")
- Firefox /Illinois: Images -> Disable Images -> All
Images
- Must repair: Does image map area alt-text describe the
link destination correctly? (fix if "no")
- Internet Explorer /AIS: Images -> Show Image
Maps
Best practice: include title as well as alt attribute
(they don't have to be identical). (fix if "no")
- Internet Explorer /AIS: Doc Info -> Show Titles
Checkpoint B, multimedia equivalents
Equivalent alternatives for any multimedia presentation shall be synchronized
with the presentation.
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.
- Must repair: Is synchronized captioning provided for all
spoken content? (fix if "no"; must repair)
- Visual and audio inspection
Checkpoint C, color
Web pages shall be designed so that all information conveyed with color
is also available without color, for example from context or markup.
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.
- Must repair: Is information conveyed by color also conveyed
by context, markup, graphic coding, or other means? (fix
if "no")
- Must repair: Does the contrast between foreground
and background colors have a luminosity contrast ratio
of least 5:1 for both normal vision and color blindness?
(fix if "no")
- Internet Explorer / AIS CSS -> Colour -> Colour Contrast Analyser : check all foreground/background combinations for sufficient contrast for sighted and color-blind users
- Internet Explorer / AIS CSS -> Colour -> Juicy Studio Colour Contrast Analyser -> Contrast Analyser -> all test [ new window] : check the page in each simulation of visual disabilities
Best practice: 10:1. (fix if "no")
- Interent Explorer / AIS CSS -> Colour -> Colour Contrast Analyser :Colour Contrast Analyser: check all foreground/background
combinations for sufficient contrast for sighted and
color-blind users
- Internet Explorer / AIS CSS -> Colour -> Juicy Studio Colour Contrast Analyser -> Contrast Analyser -> all test [ new window] Juicy Studio Colour Contrast Analyser: check the
page in each simulation of visual disabilities
Best practice: Is a correct contrast ratio maintained when images are
not available? (fix if "no")
- Firefox/developer: Images -> Disable Images -> All
Images
Checkpoint D, styles
Documents shall be organized so they are readable without requiring an
associated style sheet.
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.
- Must repair: Are
styles used to simulate headings or other semantic markup?
(fix if "yes")
- Internet Explorer /AIS: CSS -> Disable CSS
- Internet Explorer /AIS: CSS -> Structure > Headings
- Must repair: With all styles disabled,
is color and font information rendered in the browser's default
style? (fix if "no")
- Internet Explorer /AIS: CSS -> Disable CSS
- Visual inspection
- Must repair: With all styles disabled,
does the order of the page content make sense as read? (fix
if "no")
- Internet Explorer /AIS: CSS -> Disable CSS
- Visual inspection
- Must repair: With all styles disabled,
does all text (except in banner graphics) enlarge or shrink
in response to changes in browser text size settings? (fix
if "no")
- Internet Explorer /AIS: CSS -> Disable CSS
- Firefox: > Text size + & - font
Best practice: With all styles disabled,
is most text (other than logos and banners) rendered in text
rather than images? (fix if "no")
Best practice: With all styles disabled,
does any content appear that was invisible before? (fix if "yes")
Best practice: With all styles disabled,
are headings, paragraphs, and lists obvious and sensible?
(fix if "no")
Checkpoint E, server-side image maps
Redundant text links shall be provided for each active region of a server-side
image map.
Why this is important: Server-side image maps are becoming obsolete.
- Must repair: Does this page use server-side image maps?
(fix if "yes")
- Internet Explorer /AIS: Images>Show Image Maps
Checkpoint F, client-side image maps
Client-side image maps shall be provided instead of server-side image
maps except where the regions cannot be defined with an available geometric
shape.
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.)
- Must repair: Is there a non-graphic alternative
to the image map, for example a drop-down selection control?
(fix if "no")
- Visual Inspection
- Internet Explorer /AIS: Images>Show Image Maps
Checkpoint G, simple
tables
Row and column headers shall be identified for data 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."
- Must repair: For tables containing data, are <th> elements
used in the first row (and first column, if applicable)?
(fix if "no")
- Internet Explorer /AIS: Structure -> Simple Data
Table
- JAWS
- Must repair: Do <th> elements contain the scope (="col" or
="row") attribute? (fix if "no")
- Internet Explorer /AIS: Structure -> Simple
Data Table
- JAWS
- Must repair: For tables that are used for layout
only, are <th> elements or the summary attributeused
at all? (fix if "yes")
- Internet Explorer /AIS: Structure -> Simple Data
Table
- JAWS
Best practice: For tables containing data, is the summary attribute
used to explain the meaning of the table if it is not otherwise
evident from context? (fix if "no")
- Internet Explorer /AIS: Structure -> Simple Data
Table
- JAWS
Checkpoint H, complex tables
Markup shall be used to associate data cells and header cells for data
tables that have two or more logical levels of row or column headers
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.
- Must repair: For tables containing
data, are <th> elements used in the first row (and
first column, if applicable)? (fix if "no")
- Internet Explorer /AIS: Structure -> Complex
Data Table
- JAWS
- Must repair: Do <th> elements
contain the scope (="col" or ="row")
attribute? (fix if "no")
- Internet Explorer /AIS: Structure -> Complex
Data Table
- JAWS
- Must repair: For tables that are
used for layout only, are <th> elements or the
summary attribute used at all? (fix if "yes")
- Internet Explorer /AIS: Structure -> Complex
Data Table
- JAWS
- Must repair: Does each <th> element
contain the id attribute? (fix if "no")
- Internet Explorer /AIS: Structure -> Complex
Data Table
- JAWS
- Must repair: Does each <td> element
contain a headers attribute that associates it with its
column and row headers? (fix if "no")
Best practice: Use <thead> and <tbody> elements
to clarify the table structure if needed.
Best practice: find a simpler way to
present the data to all readers.
Best practice: don't use tables for
layout only.
Checkpoint I, frames
Frames shall be titled with text that facilitates frame identification
and navigation.
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.
- Must repair: Does each <frame> element have a meaningful title attribute?
(fix if "no")
- Firefox /Illinois: Navigation -> Frames
- Must repair: Does the page have equivalent content in
a <noframes> element for user agents that do not support
frames? (fix if "no")
- Internet Explorer /AIS: Structure -> Frames Name
/ Title
Checkpoint J, flicker
Pages shall be designed to avoid causing the screen to flicker with a
frequency greater than 2 Hz and lower than 55 Hz.
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.
- Must repair: Does any page element flicker at an unhealthy
rate? (fix if "yes")
- Visual inspection
- Internet Explorer /AIS: Images-> GIF Flicker
test
Best practice: Does any element on the page move at all? (fix if "yes" unless
the moving element conveys information relevant to the page
content, and then refer to checkpoints B, L, and M)
- Visual inspection
- Internet Explorer /AIS: Images-> GIF Flicker
test
Checkpoint K, text only
A text-only page, with equivalent information or functionality, shall
be provided to make a web site comply with the provisions of this part,
when compliance cannot be accomplished in any other way. The content of
the text-only page shall be updated whenever the primary page changes.
Why this is important: 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.
- Must Repair: Does this page have a text-only version?
(fix if "yes" by making the page compliant with
the rest of the checkpoints)
Checkpoint L, scripts
When pages utilize 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.
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.
- Must repair: Are HTML event handlers accessible
to both mouse and keyboard users? (fix if "no" unless
mouseovers are purely decorative; e.g., changing color of
a graphic link.)
The following "Must repair" question is
under dispute. We are currently not evaluating
Websites for an answer to this particular question. An
email will be sent to all webmasters once we receive a
decision regarding this question.
- Must repair: Is all content and functionality
generated by scripts (including href="javascript:...")
also provided to user agents that do not support scripts?
(fix if "no" unless "functionality" is
purely decorative).
- Visual Inspection
- Firefox /developer: Disable -> Disable JavaScript
-> All JavaScript (then re-load page)
Best practice: use CSS :hover in place of JavaScript and graphic
links.
Best practice: Don't use href="javascript:..." for
anything.
Checkpoint M, applets and plug-ins
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 complies with §1194.21 (a)
through (l).
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.
- Must repair: Are links provided to any special readers
or plug-ins that are required to interpret page content?
(fix if "no")
Best practice: Are documents that are presented in commonly-supported
formats such as PDF and Word constructed so as to be accessible? (fix
if "no"; requires separate evaluation)
Checkpoint N, forms
When electronic forms are designed to be completed on-line, 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.
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.
- Must repair: Does each <input> element or control
(except buttons) have an associated and visible <label> element
or title attribute? (fix if "no")
- Visual Inspection
- Jaws
- Firefox: -> Tools -> Page Information -> Forms
- Must repair: Are all cues for filling out the form (mandatory
fields, help boxes, error messages, and so on) available
to users of assistive technology? (fix if "no")
- Internet Explorer / AIS: Structure -> Show
Tab Order
- Visual Inspection
- Jaws
- Must repair: Is the tab order to reach the form
and the tab order between form elements consistent with
the normal order of entering form data? (fix if "no")
- Internet Explorer / AIS: Structure -> Show
Tab Order
- Visual Inspection
- Jaws
Best practice: Are logically-related groups of form elements identified
with appropriate <fieldset>, <legend>, or <caption> elements?
(fix if "no")
Best practice: Is placeholder text, if used, redundant or distracting
to users of assistive technology? (fix if "yes") Comment: most
properly labeled form elements no longer benefit from placeholder
text.
Checkpoint O, skip links
A method shall be provided that permits users to skip repetitive navigation
links.
Why this is important: Pages that contain
repetitive links or multiple groups of repetitive links, which a user might
want to "skip" in
whole or only in part, should contain a method for users to
jump over such links to get straight to the content of the page. Though
it has been the practice in the past to provide what is commonly referred
to as a “skip
navigation” link, assistive technologies now support navigation by
headings and lists. These constructs can be used instead of,
or in addition to “skip navigation” to organize links beneficially
for all users. New site construction should include headings, and provide
an additional method for skipping navigation if appropriate. Access keys
that may override screen reader settings should be avoided.
- Must repair: Can
a user navigate over groups of links, between multiple groups
of links, and between sections of the page content by means
of a skip navigation link or section headings? (fix if "no”)
- Internet Explorere / AIS: Structure > Headings
- Visual and functional inspection
- Internet Explorer /AIS: Structure > Show Tab Order
- Keyboard Manipulation
- JAWS
Best practice: Headings
are most helpful for users of modern assistive technology; "skip" links
and headings, however, can be used in combination where appropriate.
- Internet Explorere / AIS: Structure > Headings
- Visual and functional inspection
- Internet Explorer / AIS: Structure > Show
Tab Order
- Keyboard Manipulation
- JAWS
Checkpoint P, timed response
When a timed response is required, the user shall be alerted and given
sufficient time to indicate more time is required.
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.
- Must repair: If a timed response is required, is the user
alerted and given sufficient time to indicate that more time
is required? (fix if "no"; see also next item)
Best practice: In a timed environment such as an examination, are users
who need more time accommodated in an appropriate alternative
way? (fix if "no"; may be organizational rather than technical
solution)
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.
- Must repair: Does the text of each link describe
where the link goes? (fix if "no")
- Firefox /developer: Navigation > Links
- Must repair: Do any links with the same text point
to different places? (fix if "yes")
Best practice: are headings properly nested by level? (fix if "no")
- Firefox /developer: Navigation > Headings
Best practice: do headings accurately reflect the structure of
the document content? (fix if "no")
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.
Best practice: Is the page valid HTML? (fix if "no")Best
practice: XHTML 1.0 Strict or Transitional.
- Firefox/developer: Tools -> Validate
HTML
Best practice: Does the page use valid CSS? (fix if "no")
Best practice: CSS should be entirely separate from HTML code.
- Firefox /developer:
Tools -> Validate CSS
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 fixed.
- Must repair: Do columns, page elements, or text
lines overlap each other when text is enlarged with browser
settings? (fix if "yes")
- Firefox: > Text size + & - font
- Visual Inspection
- Must repair: Does all text (except in banner graphics)
enlarge or shrink in response to changes in browser text
size settings? (fix if "no")
- Firefox: > Text size + & - font
- Visual Inspection
Best practice: Does text enlarged with browser settings wrap
within columns? (fix if "no")
- Firefox: > Text size + & - font
- Visual Inspection
Best practice: Do actual low vision users encounter any remaining
barriers? (fix if "yes") Comment: this and the following two
items may be simulated, although actual users are best.
Best practice: Do actual blind users encounter any remaining
barriers? (fix if "yes")
Best practice: Do actual users with other disabilities encounter
any remaining barriers? (fix if "yes")
|
