HSU Checkpoints Explained

View this document as a pdf


Resources:

  • http://bobby.watchfire.com/bobby/html/en/index.jsp
  • EASI Barrier-free Web Design Workshop (version 4)
  • Paciello, Michael G. WEB Accessibility for People with Disabilities. CMP Books. Lawrence, Kansas, 2000.
  • Paciello, Mike. Accessible Web Site Creation - Simplified... Presented at CSUN Conference March 2001
  • Paciello, Mike. Accessible Web Site Creation - Advanced Design. Presented at CSUN Conference March 2001.
  • Musciano, Chuck & Kennedy, Bill. HTML - The Definitive Guide, 3 rd Edition. O'Reilly, 1998.
  • Web Content Accessibility Guidelines 1.0. W3C Note, 6-November-2000.
  • HTML Techniques for Web Content Accessibility Guidelines 1.0. W3C Note, 6-November-2000.
  • Core Techniques for Web Content Accessibility Guidelines 1.0. W3C Note, 6-November-2000.
  • CSS Techniques for Web Content Accessibility Guidelines 1.0. W3C Note, 6-November-2000 .
  • Meyer, Eric A. Cascading Style Sheets - The Definitive Guide. O'Reilly, 2000.
  • Warner, Janine and Vachier, Paul. Dreamweaver 3 for Dummies. IDG Books Worldwide, 2000.
  • Lowery, Joseph. Dreamweaver 3 Bible. IDG Books Worldwide, 2000.

    Checkpoint 1: Text Equivalents
    Checkpoint 2: Color
    Checkpoint 3: Language Changes
    Checkpoint 4: Style Sheet Options
    Checkpoint 5: Updates to Dynamic Content Text Equivalents
    Checkpoint 6: Screen Flickering
    Checkpoint 7: Clear Language
    Checkpoint 8: Image Maps
    Checkpoint 9: Client Side Image Maps
    Checkpoint 10: Data Tables
    Checkpoint 11: Data Table Markup
    Checkpoint 12: Frame Titles
    Checkpoint 13: On-line Forms
    Checkpoint 14: Programmatic Objects
    Checkpoint 15: Links to Accessible Plug-ins
    Checkpoint 16: Auditory Descriptions for Visual Tracks
    Checkpoint 17: Synchronizing Alternatives with Time-based Multimedia Presentations
    Checkpoint 18: Skipping Repetitive Navigational Links
    Checkpoint 19: Alternative, Accessible Page
  •  

    HSU Reasonably Accessible Website - Checkpoint 1 [WCAG 1.1]

    Provide a text equivalent for every non-text element (e.g., via "alt", "longdesc", or in-element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIFs), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

    English:
    Provide a text description (text equivalent) for every non-text item (non-text element). Non-text items include: images, graphical representations of text (including symbols), image map regions, animations (e.g., animated GIF's), applets and programmatic objects, ascii art, frames, scripts, images used as list bullets, spacers (invisible images used to lay out a page), graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video. The text description should provide the same information as the non-text item. Use the "alt" HTML attribute, "longdesc" HTML tag, or in element content to provide these text equivalents.

    What are text equivalents? Text equivalents are alternative representations of visual information provided in a text format. The text must convey the same function or purpose as the visual or auditory content (non-text item). When a text equivalent is presented to the user, it fulfills essentially the same function (to the extent possible) as the original content. For simple content, a text equivalent might only describe the function or purpose of content. For complex content (charts, graphs, etc), the text equivalent may be longer and include descriptive information.

    WHY?
    Any component of your website that provides visual information cannot be understood by those who cannot view it. Not only does this mean the visually impaired, but also any user who may be accessing your site with a browser or device that cannot fully display images, objects, or form elements. Images and pictures are the most common types of non-text elements used in websites. Also, images and area attributes within image maps and image-based navigation tools and form elements should have alternative text provided. This textual description should convey the same information to the user that the image or picture conveys. In movies or visual presentations, visual action such as body language or other visual cues may not be accompanied by enough information to convey the same information. Unless verbal descriptions of this visual information are provided, people who cannot see (or look at) the visual content will not be able to perceive it.

    Any component of your website that provides audio information cannot be understood by those who cannot hear it. Audio and video elements are being seen more and more as technology advances. Both of these types of non-text elements must have a text equivalent. Examples of text equivalents for audio elements are captioning and transcripts of audio information.

    Why provide equivalents as text rather than in another format? Text can be rendered in ways that are accessible to people from various disability groups using a variety of technologies. Text is considered accessible to almost all users since screen readers, non-visual browsers, and Braille readers can handle it.

    A good test to determine if a text equivalent is useful is to imaging reading the document aloud over the telephone. What would you say upon encountering this image to make the page comprehensible to the listener?

     

    HSU Reasonably Accessible Website - Checkpoint 2 [WCAG 2.1]

    Ensure that all information conveyed with color is also available without color, for example from context or markup.

    English:
    Do not rely on color alone to convey information. Ensure that graphics are understandable when viewed without color.

    WHY?
    Users who are color-blind or are using a device that isn't capable of color display are not able to perceive such emphasis. If color alone is used to convey information, people who cannot differentiate between certain colors and users with devices that have non-color or non-visual displays will not receive the information.

    Also, do not rely on user's perception of color to differentiate items on a page. For example, when asking for input from users, do not write, "Please select an item from those listed in green." Instead, ensure that information is available through other style effects (e.g., a font effect or in graphics, different shapes) and through context (e.g., comprehensive text links). It is recommended that you use style sheets to specify text and background colors so that users can override color choices with their own style sheets.

    To test whether your document still works without colors, examine it with a monochrome monitor or, print it on a black and white printer, or view with browser colors turned off. Also, try setting up a color scheme in your browser that only uses black, white, and the four browser-safe grays and see how your page holds up.

     

    HSU Reasonably Accessible Website - Checkpoint 3 [WCAG 4.1]

    Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).

    English:
    Identify changes in the primary language of a document's text and any text equivalents.

    WHY?
    Identifying language changes on multilingual web pages helps a browser to display text appropriately for that language, and allows access aids such as speech synthesizers and Braille devices to pronounce text using language-appropriate pronunciation rules. For example, Braille translation software will generate the correct characters (accented characters); speech synthesizers that "speak" multiple languages will be able to generate the text in the appropriate accent with proper pronunciation. When abbreviations and natural language changes are not identified, they may be indecipherable when machine-spoken or Brailled.

    In addition to helping assistive technologies, natural language markup allows search engines to find key words and identify documents in a desired language. Natural language markup also improves readability of the Web for all people, including those with learning disabilities, cognitive disabilities, or people who are deaf.

     

    HSU Reasonably Accessible Website - Checkpoint 4 [WCAG 6.1]

    Organize documents so they may be read without style sheets. For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document.

    English:
    If you use style sheets, organize your documents so that they may be read if a user's browser does not support style sheets or if a user has chosen to turn style sheets off.

    WHY?
    Since style sheets are a new feature, older browsers will not support them and it will take a while for new browsers to support them in a standard way. When content is organized logically, it will be displayed in a meaningful order even when style sheets are turned off or not supported. One way of testing this is to place style information in a separate file rather than inline and temporarily rename that file while testing.

     

    HSU Reasonably Accessible Website - Checkpoint 5 [WCAG 6.2]

    Ensure that equivalents for dynamic content are updated when the dynamic content changes.

    English:
    If you have dynamic content in your pages (i.e., content that changes), ensure that text equivalents provided are updated when the dynamic content changes.

    WHY?
    Text generated by style sheets is not part of the document source and will not be available to assistive technologies. Any dynamic content should have an alternative presentation that does not rely on the interactive capabilities of the user agent. Being on the cutting edge can be fun, but be aware than many of your users may not have a user agent capable of rendering new content formats. Ensure that important content appears in the document object.

     

    HSU Reasonably Accessible Website - Checkpoint 6 [WCAG 7.1]

    Until user agents allow users to control flickering, avoid causing the screen to flicker.

    English:
    Do not cause the screen to flicker because browsers are not capable of allowing users to control flickering.

    WHY?
    Screen flickering or flashing in the 4 to 59 flashes per second (Hertz) range can trigger seizures in people with photosensitive epilepsy. Quick changes from dark to light, like strobe lights, can also trigger seizures.

    Programmatic objects, such as applets, plug-ins, scripts, and animated images and movies, may have features that have the effect of causing the screen to flicker. Quick motion, sudden changes in color, and other devices designed to capture the user's attention may have this effect. Use care when designing or selecting these media.

     

    HSU Reasonably Accessible Website - Checkpoint 7 [WCAG 14.1]

    Use the clearest and simplest language appropriate for a site's content.

    English:
    Use the clearest and simplest language appropriate for the users you anticipate to visit your site.

    WHY?
    Using clear and simple language promotes effective communication. Access to written information can be difficult to impossible for people who have cognitive disabilities, learning disabilities, or who are deaf or hard of hearing. This consideration also applies to the many people whose first language differs from that of the web page. Consistent page layout, recognizable graphics, and easy to understand language benefits all users.

    Note: Bobby cannot evaluate the writing on your web page. It raises this issue for every page. If you have used clear and simple language, your page may be in conformance with this checkpoint.

     

    HSU Reasonably Accessible Website - Checkpoint 8 [WCAG 1.2]

    Provide redundant text links for each active region of a server-side image map.

    English:
    If you have a server-side image map, provide redundant text links for each active region.

    WHY?
    Image maps are images in which regions of the image contain "hot spots" where a person can click to follow a link. Because the actual links are stored on the server, the browser cannot provide the links to the user. Provide text links corresponding to all hot-spots somewhere on the page.

    Not all browsers can use server-side image maps, which rely on access to images and a mouse. This is important for users who have turned off image-loading in their Web browsers, those using text-based browsers like Lynx, and people who have visual or cognitive disabilities and require the use of a screen reader to read the contents of the screen.

    Any component of your website that provides visual information cannot be understood by those who cannot view it. Not only does this mean the visually impaired, but also any user who may be accessing your site with a browser or device that cannot fully display images, objects, or form elements.

     

    HSU Reasonably Accessible Website - Checkpoint 9 [WCAG 9.1]

    Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.

    English:
    If you use image maps, provide client-side image maps instead of server-side image maps whenever possible.

    WHY?
    Server side image maps are so called because the information about which regions of the image should link to what URL is stored on the web server, rather than made available to the user's browser. This makes it impossible for access aids to provide access to the image map via other means than through the mouse, e.g., via keyboard controls). If the image is not displayed, the image map becomes non-existent. Use of client side image maps allows the user's browser or access aids to bypass these problems, even if the image itself is not actually displayed.

     

    HSU Reasonably Accessible Website - Checkpoint 10 [WCAG 5.1]

    For data tables, identify row and column headers.

    English:
    If you use data tables, identify row and column headers.

    WHY?
    Identifying row and column headers for truly tabular information ("data tables") is important to the computer's ability to speak the contents of a table using a speech synthesizer. Browsers and assistive technologies rely on structural markup such as headers to customize presentation to meet a user's needs. Some user agents allow users to navigate among table cells and access header and other table cell information. Unless marked-up properly, these tables will not provide user agents with the appropriate information.

    Tables should be used to mark up data tables; avoid using them to layout pages ("layout tables"). Also, it is important not to use the TH element to achieve formatting (such as bold text in layout tables); use other means to do that. The semantic meaning of the TH element is important to many access aids.

     

    HSU Reasonably Accessible Website - Checkpoint 11 [WCAG 5.2]

    For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

    English:
    If you use data tables, use HTML codes (markup) to associate the data in the cells to the header cells.

    WHY?
    This is important to the computer's ability to speak the contents of a table using a speech synthesizer. Browsers and assistive technologies rely on structural markup such as headers to customize presentation to meet a user's needs. If there is more than one row or column of headers, a more extensive description of the relationship between cells helps the user understand the structure better.

     

    HSU Reasonably Accessible Website - Checkpoint 12 [WCAG 12.1]

    Title each frame to facilitate frame identification and navigation.

    English:
    If you use frames, title each frame.

    WHY?
    A frame title gives the user information about the contents of the frame, if they are not able to access multiple frames simultaneously. With this information they can pick which particular frame to view. Individuals using screen readers or self-voicing browsers can identify the number of frames presented on a Web page. And, if properly coded (using the title attribute), they may be able to tell you the general contents of a frame.

    Note: Frames aren't just a navigational challenge for individuals who are blind. They tend to present a total comprehension problem. The use of frames may make it easier for the Web designer to present multiple windows of static information, but it cuts against the grain of the standard human reading paradigm. Furthermore, users with text browsers are sometimes completely locked out of a page with frames.

     

    HSU Reasonably Accessible Website - Checkpoint 13 [Section 508 - n]

    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.

    English:
    When designing on-line forms, position fields and their labels in such a way that it is apparent what labels are associated with what fields.

    WHY?
    Users who do not have a view of the web page in a graphical layout may not be able to determine which label applies to which form control, and therefore will not know what data to enter. Proper positioning of the label helps to avoid this.

    Note: this is triggered by the presence of form controls on your page. Bobby cannot determine whether their labels are properly positioned. If they are, this technique does not apply.

     

    HSU Reasonably Accessible Website - Checkpoint 14 [WCAG 6.3]

    Ensure that pages are usable when scripts, apples, or other programmatic objects are turned off or not supported.

    English:
    If you use applets and scripts, ensure pages are usable when scripts, applets, or other programmatic objects are turned off or not supported by a user's browser applications. If this is not possible, provide an alternative page that is accessible and contains equivalent information.

    WHY?
    There is no guarantee that a particular object will perform as intended or at all. Browsers vary widely in their support of these objects, and many of these objects do not have intrinsic accessibility features. Although authors are encouraged to use new technologies that solve problems raised by existing technologies, they should know how to make their pages still work with older browsers and people who choose to turn off features.

    Screen readers have a great deal of difficulty rendering correctly scripts, applets, and plug-ins.

    Ensure that pages are accessible (transform gracefully) even when newer technologies are not supported or are turned off. Any dynamic content should have an alternative presentation that does not rely on the interactive capabilities of the user agent. Ensure that important content appears in the document object. Text generated by style sheets is not part of the document source and will not be available to assistive technologies.

     

    HSU Reasonably Accessible Website - Checkpoint 15 [Section 508 - m]

    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.

    English:
    If your webpage contains items that require an applet, plug-in, or other application, make sure there is a link to download accessible plug-ins.

    WHY?
    Plug-in content, by definition, requires a browser plug-in for it to be viewed. If the user has not encountered a particular content type before they may not have the appropriate plug-in, or know where to get it. Provide a link to download an accessible plug-in. It is important to link to an accessible plug-in; an inaccessible plug-in, while it may render content to average users, may not render content to users with disabilities.

     

    HSU Reasonably Accessible Website - Checkpoint 16 [WCAG 1.3]

    Until user agents can automatically read aloud the text equivalent of a visual track, provide an auditory description of the important information of the visual track of a multimedia presentation.

    English:
    If you use multimedia, provide auditory descriptions of the important information of visual tracks of a multimedia presentation because assistive technologies cannot automatically read aloud the text equivalent of a visual track.

    WHY?
    Any component of your website that provides visual information cannot be understood by those who cannot view it. Not only does this mean the visually impaired, but also any user who may be accessing your site with a browser or device that cannot fully display images, objects, or form elements. In movies or visual presentations, visual action such as body language or other visual cues may not be accompanied by enough information to convey the same information. Unless verbal descriptions of this visual information are provided, people who cannot see (or look at) the visual content will not be able to perceive it. Descriptive video provides a blind or low vision user with additional narrative that is useful and sometimes critical to their comprehension of an electronic document. Key visual elements include actions, settings, body language, graphics and displayed text. The process simply requires the interjection of descriptive narration during the spots within the video that are not otherwise filled with sound effects or dialogue. As a result, the blind or visually impaired viewer achieves increased comprehension of the video event.

     

    HSU Reasonably Accessible Website - Checkpoint 17 [WCAG 1.4]

    For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.

    English:
    If you use multimedia, synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with any time-based multimedia presentation.

    WHY?
    Any component of your website that provides auditory (or visual) information cannot be understood by those who cannot hear (or view) it. Audio and video elements are being seen more and more as technology advances. Both of these types of non-text elements must have a text equivalent, and the text equivalent should be synchronized with the presentation.

    Examples of text equivalents for audio elements are captioning and transcripts of audio information. Captions should include speech as well as other sounds in the environment that help viewers understand what is going on.

     

    HSU Reasonably Accessible Website - Checkpoint 18 [Section 508 - o]

    A method shall be provided that permits users to skip repetitive navigation links.

    English:
    Provide a way for users to skip repetitive navigational links.

    WHY?
    Allowing users to skip links facilitates access to the important content without being bogged down in a set of links if they don't need them. For example, the navigation bar is usually the first thing someone encounters on a page. For users with non-visual displays, who cannot skim easily, this means having to hear a number of links on every page before reaching the content of a page.

    Bobby cannot determine if links are intended for navigation or if they have means to skip them. This issue is raised for all pages. If you have provided a means to skip navigation links, your page may be in conformance with this technique.

     

    HSU Reasonably Accessible Website - Checkpoint 19 [WCAG 11.4]

    If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

    English:
    If you cannot make a page accessible, provide a an alternative page that is accessible, has equivalent information (or functionality), and is updated as often as the original (inaccessible) page.

    WHY?
    While most web pages can be made accessible, there are cases in which one can't while retaining the designer's intention. Web page designers should only resort to alternative pages when other solutions fail because alternative pages are generally updated less often than "primary" pages. An out-of-date page may be as frustrating as one that is inaccessible since, in both cases, the information presented on the original page is unavailable. Automatically generating alternative pages may lead to more frequent updates, but content developers must still be careful to ensure that generated pages always make sense, and that users are able to navigate a site by following links on primary pages, alternative pages, or both.