“Smart design removes barriers”

Phone 714.968.0636 - Email tom [at] tomjewett [dot] com

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

1. 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)
   • How: Visual check.
2. 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.
3. 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")
4. 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.
5. 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.)
6. 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).
7. 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.)
8. 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.
9. 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)
   • How: Visual check.
10. 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.
11. 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. (2.4, 3.2)
    • How: Toolbar, Information -> Display Tab Index; Forms -> Display Form Details; Forms -> View Form Information.
12. Video: Video must be captioned (open or closed captioning). (1.2)
    • How: Visual check.
13. 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 compliance (green check mark) or not (red X) for HTML, CSS, and JavaScript, in that order.
    • 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.