As directed by Governor Davis in Executive Order D-17-00 issued on September 8, 2000, a comprehensive eGovernment initiative was launched that requires every agency and department to adhere to technical standards for accessible Web design and compatibility. This Accessibility Guide enables webmasters to utilize the best tools and design available to ensure that the content of State websites can be reached by the widest possible audience regardless of disability, limitations of computer equipment or use of alternate Internet access devices.
In addition, this Accessibility Guide enables webmasters to meet State and Federal statutory requirements prohibiting discrimination against people with disabilities in the design of both Internet and Intranet web sites. For example, California Government Code Section 11135 et seq. prohibits discrimination by entities receiving funding from the State of California.
Likewise, Federal requirements mandating access for persons with disabilities were first imposed on State recipients of Federal funding by the Rehabilitation Act of 1973. Today there are numerous Federal statutes and regulations extending civil rights protections to persons with disabilities, including the Americans with Disabilities Act of 1990 (ADA), as well as the 1998 Amendments to the Rehabilitation Act, where specific technical requirements for accessible web design have been published by the U.S. Access Board. This is important since Title II of the ADA recognizes the importance of communication and the necessity of the State of California to take appropriate steps to ensure that communications with persons with disabilities are as effective as communications with others.
Between 17% and 19% of United States citizens have some level of disability. In fact, about l out of 5 Americans have some form of disability and 1 in 10 have a severe disability. These 1997 statistics by the U.S. Census Bureau also report that with the population aging and the likelihood that disabilities can increase with age, the growth in the number of people with disabilities is expected to accelerate in the coming decades. See Census Brief, December 1997.
To have effective communication with the widest audience possible, this Accessibility Guide provides assistance in how to use alternate forms of communication. Disabilities can fall into four basic categories:
But the digital divide does not just affect people with disabilities. People without disabilities who have busy hands or eyes, poor lighting or noisy surroundings will find the My California portal very user-friendly. People with slow modems, older browsers, or those using alternate internet access devices (e.g., cellular telephones, personal digital assistants, etc.) will also benefit from a highly accessible web site. This Accessibility Guide will continue to be updated as technology evolves and new tools and resources for accessibility are developed.
The State of California has adopted the following selected rules from the W3C Web Content Accessibility Guidelines 1.0 W3C Recommendation 5-May-1999. Technical assistance in this Accessibility Guide is drawn from both the W3C technical assistance materials as well as the 2001 U.S. Department of Justice Web Accessibility Questionnaire.
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), animations (e.g. animated GIFs), applets and programmatic objects, ascii art, 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. [W3C WCAG 1.1]
Ensure that all information conveyed with color is also available without color, for example from context or markup. [W3C WCAG 2.1]
Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions). [W3C WCAG 4.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. [W3C WCAG 6.1]
Ensure that equivalents for dynamic content are updated when the dynamic content changes. [W3C WCAG 6.2]
Until user agents allow users to control flickering, avoid causing the screen to flicker. [W3C WCAG 7.1]
Use the clearest and simplest language appropriate for a site's content. [W3C WCAG 14.1]
Provide redundant text links for each active region of a server-side image map. [W3C WCAG 1.2]
Provide client-side image maps instead of server -side image maps except where the regions cannot be defined with an available geometric shape. [W3C WCAG 9.1]
For data tables, identify row and column headers. [W3C WCAG 5.1]
For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells. [W3C WCAG 5.2]
Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page. [W3C WCAG 6.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. [W3C WCAG 1.3]
For any time-based multimedia presentation (e.g. movie or animation), synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation. [W3C WCAG 1.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. [W3C WCAG 11.4]
Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned. [W3C WCAG 10.2 Priority Level 2]
Associate labels explicitly with their controls. [W3C WCAG 12.4 Priority Level 2]
It is highly recommended by the W3C that validation methods be utilized. Please see Appendix A of the W3C Web Content Accessibility Guidelines 1.0 for further information.
Adobe Portable Document Format (PDF) documents have many advantages for use on the internet, including cross-platform capability, precise control over layout, internal navigation and searchability. However, PDF documents may not be viewable by alternate Internet access devices (ie., cell phones, personal digital assistants) or assistive computer technology (including text browsers and screenreaders). In order to deliver content to the maximum number of visitors, be sure to provide alternate means for accessing information contained in PDF documents. Ideally, an HTML version of the document should also be posted with the PDF version. However, other alternative formats include plain text documents or word processor documents such as Word or WordPerfect files. Another option to consider is Adobe's PDF Conversion by Simple Form, which provides on-the-fly conversion of PDF documents into HTML. If you use this form of conversion, you must test it to make sure the results are acceptable before posting the converted document.
According to the 2001 U.S. Department of Justice Web Accessibility Questionnaire, PDF documents can be created in a number of different ways and each method has separate implications for accessibility:
The US Department of Justice continues by stating that the last two methods of creating PDF files should be utilized, if necessary, and that webmasters should avoid the first method entirely. For further information, see "How to Create Accessible Adobe PDF Files Booklet" at http://access.adobe.com/booklet.html.
Lastly, the accessibility of PDF documents should be tested with screenreaders before posting on the web site and if web-based documents are published in PDF, then the same document should be simultaneously published in another accessible format, such as HTML. The Adobe PDF Conversion by Simple Form tool can be used by webmasters to convert the document, proof it for accuracy and then post in accessible HTML. See http://access.adobe.com/simple_form.html.
When posting forms remember to provide alternate access to the forms for those using technology that is not supported by JavaScript. Note comments under Forms as well as Applets and Scripts.
W3C Web Accessibility Initiative http://www.w3.org/WAI
W3C Techniques http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#Techniques
W3C Evaluation, Repair and Transformation Tools http://www.w3.org/WAI/ER/existingtools.html
HTML Writers Guild Accessible Web Authoring Resources and Education Center http://aware.hwg.org
Federal IT Accessibility Initiative http://www.section508.gov