"Smart design removes barriers"

Phone 714.235.1694 - Fax 714.242.6657 - Email info@theenabledweb.com

Smart analysis simplified (Basic web view)

This human-intelligence-based method can quickly determine if the most important elements of a web page can be used by most persons with visual, cognitive, and other disabilities. The description of "How:" each check is done refers to the Firefox browser with the Illinois toolbar (see "Our toolkit" sidebar on this page). We can train your developers and vendors to use this and other methods, in much more detail than it's possible to present here.

Yes, this is the basic protocol that we use, perhaps modified slightly at times to fit a particular set of requirements. For a very quick accessibility check, we have found than many of the most important barriers on a page can be identified with only the five tests marked "(quick check)": headings, links, images, forms, and styles. (For a short list, see the steps only view of this page.)

1. Validation check: HTML and CSS code should comply with W3C standards.
   • How (HTML): Validators -> W3C HTML Validator;
   • for CSS: Validators -> W3C CSS Validator;
   • for language: Navigation -> Language Changes.
2. Visual check: All text should be easily legible to fully-sighted readers. When text is enlarged in the browser, all text (except banner logos) should respond and nothing should overlap or be hidden. Make sure nothing is flickering or flashing. Make sure the Title of the page (in the browser title bar) is descriptive of the content.
   • How: Ctrl+ three times; Ctrl- to reduce; check Title and look for flashing.
3. Dynamic elements: These include multimedia, applets, scripts, and timed-response events. This quick check will identify only the most obvious barriers; most dynamic elements will require specialized, detailed analysis to insure that they are accessible to all readers.
   • How: Visually check for captions and timed events; use all dynamic elements with keyboard only.
4. Text only: A text-only alternate page is almost always an insurmountable barrier for the disabled, since it contains no structure or other navigation aids that can be used by voice readers. In special circumstances, an HTML-only page might be a useful alternative—for example, to an all-Flash page—but the alternate must convey the same content and will require its own check as shown on this page.
   • How: Visual inspection; may also discover when checking links, images, or styles, below.
5. Color: Make sure that information is not conveyed by color alone. Verify that color contrast is sufficient for fully sighted and color-blind readers.
   • How: Visual inspection; Style -> Colour Contrast.
6. Headings: (quick check) Headings should match the actual semantic structure of the document and should be properly nested by level. Headings should also be used to identify and navigate between groups of related links. Proper use of headings is now more accessible than adding "skip navigation" links.
   • How: Navigation -> Headings; Navigation -> Menu and Navigation Bars.
7. Image maps: Each active area of an image map must have associated link text (this is also checked under "links" and "images" below). The map information box may incorrectly "fail" the page for not having identical redundant text links, which are required only for server-side image maps—which should not be used anyway. The map title is optional if the purpose of the image can be determined from context. (The "title" shown in the map information box simply represents a heading immediately preceeding the image.)
   • How: Navigation -> Image Maps.
8. Links: (quick check) 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 have the same text each time. If any link has "javascript" as the target, it is likely to be an accessibility barrier that will require additional evaluation. All links should be reachable and visible using only the Tab key.
   • How: Navigation -> Links; down-arrow through list and watch position on screen.
9. Forms: (quick check) 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. (Click a control name in the form list to identify these if present.) The form title is optional if the purpose of the form can be determined from context. "Placeholder" text inside text boxes is no longer needed for screen readers; it is redundant in a properly-labeled form. Many forms will also have to be evaluated separately for dynamic behavior such as error response.
   • How: First tab through the form controls, then select Navigation -> Forms.
10. Frames: Frames should never be used in new development, since the same functionality can be achieved in more accessible ways. For legacy sites that do use them, each frame must have a descriptive title to facilitate navigation between them. Frames must be re-sizable to accommodate text enlargement for low-vision users, and scrollable where necessary. They must provide access to the same content for user agents that do not support frames.
    • How: Navigation -> Frames.
    • To check resizing, repeat the visual check of step 1, and resize frames if possible.
    • To check behavior without frames, use the Firefox menu bar, View -> Page Source, and evaluate the content within the <noframes> element (which must be present).
11. Images: (quick check) With images replaced by their text equivalents, no information or navigation should be lost to any visitor to the page. Purely decorative images should have null (empty) text equivalents, although those will be flagged incorrectly as errors if you happen to look at the toolbar List of Images.
    • How: Text Equivalents -> Show Text Equivalents. (Leave checked)
12. Styles and layout: (quick check) With styles (CSS and tag styling) off, the semantic structure of the page content should be readily understandable from the browser's default rendering (of headings, lists, and so on) and navigable by assistive technologies. No content should appear that was made visible by CSS solely with mouse action (hover) or otherwise hidden from sighted readers. With layout tables removed, the page should read in logical order from top to bottom; use of layout tables should be kept to an absolute minimum.
    • How: Style -> uncheck Author CSS; Style -> uncheck Tag Styling; Style -> uncheck Table Layout. (Leave these settings)
13. Data Tables: Layout tables (those with no 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.
    • How: Navigation -> Data Tables. In the popup window, click on the table Title and use the Left/Up/Right/Down buttons to see headers as each cell is highlighted.

To finish, select Options -> Reset styling and settings and reload the page.

The legal stuff

Copyright 2008–09, by Tom Jewett, tom@theenabledweb.com. Please see our home page for full legal notices.