Submitted by Governor's Office of Innovation & Technology (OIT)
ADA Standards (for visually impaired) Work Committee
January 12, 2001
The following ADA Standards were adopted by the Commission on Information Management (IMC) as required by House Bill 00-1269, approved June 1, 2000, for information technology access for individuals who are blind or visually impaired.
HB 1269 requires:
Please note that HB 1269 does not require the installation of software or peripheral devices used for nonvisual access when the IT is being used by individuals who are not blind or visually impaired or the purchase of nonvisual adaptive equipment.
In December 2000, the Governor's Office of Innovation and Technology (OIT) assembled a work committee to develop ADA standards for information technology access for individuals who are blind or visually impaired per the requirements established by HB 1269. The ADA Standards Work Committee is comprised of a cross section of private and public sector individuals as well as visually impaired persons. The Committee met initially on December 18, 2000 to develop proposed standards, using the W3C guidelines as its primary source document. On December 21, 2000 the Department of Justice issued its final accessibility standards for information technology as required by section 508 of the Rehabilitation Act Amendments of 1998. The Committee met again on January 8, 2001and compared the W3C guidelines with the applicable portions of the Department of Justice standards. Because the W3C standards were substantially integrated into the Department of Justice section 508 standards, the following recommended standards comport with both the applicable Department of Justice section 508 standards and the W3C private sector guidelines.
Pursuant to the dictates of HB 1269, the Work Committee's initial proposed standards focus on design criteria for web-based publicly accessible information. The standards cover the following specific categories: Equivalents, Color, Markup Language/Style Sheets, Tables, Natural Language, Time-Sensitive Content, and Dynamic Content and Device Independent.
Due to the quickly changing nature of technology, the ADA Standards Work Committee recommends that annual reviews of these standards be reviewed on annually and updated appropriately.
Device independent: Users must be able to interact with a user agent (and the document it renders) using the supported input and output devices of their choice and according to their needs. Input devices may include pointing devices, keyboards, Braille devices, head wands, microphones, and others. Output devices may include monitors, speech synthesizers, and Braille devices.
Please note that device-independent support does not mean that user agents must support every input or output device. User agents should offer redundant input and output mechanisms for those devices that are supported. For example, if a user agent supports keyboard and mouse input, users should be able to interact with all features using either the keyboard or the mouse.
M.Document Content, Structure, and Presentation: The content of a document refers to what it says to the user through natural language, images, sounds, movies, animations, etc. The structure of a document is how it is organized logically (e.g., by chapter, with an introduction and table of contents, etc.). An element (e.g., P, STRONG, BLOCKQUOTE in HTML) that specifies document structure is called a structural element. The presentation of a document is how the document is rendered (e.g., as print, as a two-dimensional graphical presentation, as a text-only presentation, as synthesized speech, as Braille, etc.). An element that specifies document presentation (e.g., B, FONT, CENTER) is called a presentation element.
Consider a document heading, for example. The content of the heading is what the heading says (e.g., Sailboats). In HTML, the heading is a structural element marked up with, for example, an H2 element. Finally, the presentation of the heading might be a bold block text in the margin, a centered line of text, a title spoken with a certain voice style (like an aural font), etc.
Element: This document uses the term element both in the strict SGML sense (an element is a syntactic construct) and more generally to mean a type of content (such as video or sound) or a logical construct (such as a heading or list). The second sense emphasizes that a guideline inspired by HTML could easily apply to another markup language.
Note that some (SGML) elements have content that is rendered (e.g., the P, LI, or TABLE elements in HTML), some are replaced by external content (e.g., IMG), and some affect processing (e.g., STYLE and SCRIPT cause information to be processed by a style sheet or script engine). An element that causes text characters to be part of the document is called a text element.
Equivalent: Content is equivalent to other content when both fulfill essentially the same function or purpose upon presentation to the user. In the context of this document, the equivalent must fulfill essentially the same function for the person with a disability (at least insofar as is feasible, given the nature of the disability and the state of technology), as the primary content does for the person without any disability. For example, the text The Full Moon might convey the same information as an image of a full moon when presented to users. Note that equivalent information focuses on fulfilling the same function. If the image is part of a link and understanding the image is crucial to guessing the link target, an equivalent must also give users an idea of the link target. Providing equivalent information for inaccessible content is one of the primary ways authors can make their documents accessible to people with disabilities.
As part of fulfilling the same function of content, an equivalent may involve a description of that content (i.e., what the content looks like or sounds like). For example, in order for users to understand the information conveyed by a complex chart, authors should describe the visual information in the chart.
Since text content can be presented to the user as synthesized speech, Braille, and visually displayed text, these guidelines require text equivalents for graphic and audio information. Text equivalents must be written so that they convey all essential content. Non-text equivalents (e.g., an auditory description of a visual presentation , a video of a person telling a story using sign language as an equivalent for a written story, etc.) also improve accessibility for people who cannot access visual information or written text, including many individuals with blindness, cognitive disabilities, learning disabilities, and deafness.
Equivalent information may be provided in a number of ways, including through attributes (e.g., a text value for the alt attribute in HTML and SMIL), as part of element content (e.g., the OBJECT in HTML), as part of the document's prose, or via a linked document (e.g., designated by the longdesc attribute in HTML or a description link). Depending on the complexity of the equivalent, it may be necessary to combine techniques (e.g., use alt for an abbreviated equivalent, useful to familiar readers, in addition to longdesc for a link to more complete information, useful to first-time readers).
One example of a non-text equivalent is an auditory description of the key visual elements of a presentation. The description is either a pre-recorded human voice or a synthesized voice (recorded or generated on the fly). The auditory description is synchronized with the audio track of the presentation, usually during natural pauses in the audio track. Auditory descriptions include information about actions, body language, graphics, and scene changes.
Image map: An image that has been divided into regions with associated actions. Clicking on an active region causes an action to occur.
When a user clicks on an active region of a client-side image map, the user agent calculates in which region the click occurred and follows the link associated with that region. Clicking on an active region of a server-side image map causes the coordinates of the click to be sent to a server, which then performs some action.
Content developers can make client-side image maps accessible by providing device-independent access to the same links associated with the image map's regions. Client-side image maps allow the user agent to provide immediate feedback as to whether or not the user's pointer is over an active region.
Colorado.gov officially supports any browser that is used by more than 5% of the visitors to the site in the most current quarter. As of 7/31/2006, the following list of browsers are supported: