On this site
The analysis steps on this page require no knowledge
of programming languages, and use only three tools to assist the
analyst—all of which may be downloaded for free.
- The Firefox browser,
(http://www.mozilla.com/en-US/) for which
many other free tools have been developed both to assist in
accessibility analysis and to directly assist persons with disabilities.
We use it for one simple reason: it runs on all desktop operating systems.
Web Developer toolbar.
It has many more features than we need here, but it can check most accessibility
concerns except the following:
Contrast Checker for Firefox.
There are other similar checkers, but this is the only one we've found that is
integrated into the browser.
Smart analysis simplified
This human-intelligence-based method can quickly and easily
determine if the most important elements of a web page
can be used by most persons with visual, cognitive, and other disabilities. It is a revision and
update of a procedure developed by Tom Jewett and Wayne Dick for use by the 23 campuses of the
California State University in their Accessible Technology Initiative. It assumes familiarity
with the WC3 Web Content
Accessibility Guidelines (WCAG), and is not intended to provide comprehensive coverage of all
requirements contained in that document. Numbers in parentheses after each check (e.g. 1.1) indicate
the WCAG guidelines that are relevant to that check.
The description of how each check is done refers to the Firefox browser with the
Web Developer toolbar
(see "Our toolkit" sidebar on this page), unless otherwise stated.
We can train
your developers and vendors to use this and other methods.
The W3C/WAI Education and Outreach working group is developing a testing procedure
that is similar to this one in many ways. We encourage you to
refer to their "Easy Checks" [Rough Draft]
document for much more detail than we can present here. Guidelines for full commercial-level
accessibility audits are contained in the W3C
Website Accessibility Conformance Evaluation Methodology.
–Latest update: 10/29/13
- Page title and movement: Make sure the Title of
the page (in the browser title bar) is descriptive of the content. Also look at the page
contents to be sure nothing is moving or flashing without some obvious way to stop it.
(2.2, 2.3, 2.4)
- Text enlargement: All text should be easily legible to fully-sighted readers.
When text is enlarged in the browser for low-vision readers, all text (except logo images) should
respond and nothing should overlap or be hidden. (1.4)
- How: First, from the Firefox menu, check View -> Zoom -> Zoom Text Only. Then press
Ctrl-+ at least four times (command-+ on the Mac). Ctrl-0 (command-0) returns to normal size.
- Keyboard operation: All controls should be reachable and
operable using the keyboard only. Sighted readers should be able to see the location of each
active control or link. (2.1, 2.4)
- How: Use the Tab key to navigate through the
entire document. (Mac users may have to
go to System Preferences -> Keyboard -> Keyboard Shortcuts -> in "Full Keyboard Access"
section, check "All Controls")
- Color and Luminance: Make sure that information is not conveyed
by color alone. Also make sure that luminance contrast (usually and incorrectly called "color"
contrast) is sufficient for fully sighted and color-blind readers. (1.4)
- How: From the Firefox menu, select Tools -> Color Checker. The add-in sidebar has many
features; experiment to find the easiest for you to use. Visually check for use of color
only to convey information.
- Visual "voice reader" simulation: Although we'll check
individual items in more detail below, this test will let you see how most of the page will be read aloud
(with a few exceptions). If anything looks awkward or confusing, it's fairly certain to
sound even more awkward or confusing. (1.3)
- How: Toolbar, Miscellaneous -> Linearize Page; Images -> Replace Images With Alt
Attributes; CSS -> Disable Styles -> Disable All Styles. (Reload page when finished.)
- Document structure: Headings should match the actual semantic structure of
the document and should be properly nested by level unless the <h1> is preceeded by navigation.
Headings should also be used to identify and navigate between groups of related links, and
between links and main content. (2.4)
- How: Toolbar, Information -> View Document Outline (opens in new tab).
- Links: All links must have text; each link's text should describe
its destination clearly; if link titles are present, they should not duplicate the
link text; duplicate link text should not point to different destinations, but
links that point to the same destination should normally have the same text unless there
is a reason to differentiate them. (2.4)
- How: Toolbar, Information -> Display Link Details. (Re-click menu option to toggle
off, or simply reload page when finished.)
- Images: With images replaced by their text equivalents, no information
or navigation should be lost to any visitor to the page. Every image must have an alt
attribute; for any purely decorative image, it should be null (alt=""). (1.1)
- How: Toolbar, Images -> Display Alt Attributes.
- Image maps: Image maps should have equivalent information available
(on the same page) in text form that is also keyboard accessible. If the map is generated
from a database, then the equivalent (for example, a data table) must be generated from the
same database information. (1.1)
- Tables: Tables used for layout only should never have heading
elements, should never be
used to contain truly tabular data, and should never have summary attributes. True data tables
should have each data cell associated with its column (and row, if appropriate) header or headers.
Complex tables should have each data cell associated with all applicable heading levels. (1.3)
- How: Toolbar, Outline -> Outline Tables -> Outline Table Cells; then Information ->
Display Table Information.
- Forms: Each form control must have an associated label that describes
its purpose. Tab order between form controls must match the order in which a user
would normally complete them.
Complex forms benefit from grouping controls with the fieldset element.
The form title is optional if the purpose of the form can be determined from context. Many
forms will also have to be evaluated manually for dynamic behavior such as error response.
- How: Toolbar, Information -> Display Tab Index; Forms -> Display Form Details;
Forms -> View Form Information.
- Video: Video must be captioned (open or closed captioning). (1.2)
- Validation check: HTML and CSS code should comply with W3C standards.
Note that any error messages may need careful evaluation of the code; for example, a single
missing punctuation character might cause multiple subsequent "failures." (4.1)
- Note: Both the toolbar indicators and the W3C's own
validator will flag any use of CSS3 as an error! (It's not.)
- How (quick way): Check the three icons at the right end of the Toolbar. They indicate
- How (detailed way): Toolbar, Tools: Validate HTML; Tools -> Validate CSS.
The legal stuff
Copyright 2008–2013, by Tom Jewett, tom [at] tomjewett [dot] com.
Please see our home page for full legal notices.