Examples of Accessibility Policies
Examples of Web Accessibility Policies in Practice and Suggested Policies for Use
1. List Includes Examples of University/Postsecondary Web Accessibility Policies in the U.S.
by Cyndi Rowland, WebAIM, Utah State University. This list is a sample of some institutional policies in higher education regarding Web accessibility. These institutions represent a portion of the current range of accessibility policies that are in place. In some instances you will see well articulated, institutionally approved policies that specify exact elements that must be made accessible by Web developers. In other institutions, you will see statements to encourage Web developers to design accessibly with or without specifics as to how this can be accomplished. http://www.webaim.org/articles/upolicies
2. State of Connecticut Universal Web Site Accessibility Policy for State Web Sites http://www.cmac.state.ct.us/access/policies/accesspolicy40.html#Checklist
3. Plan for Institutional Coordination and Reform to Support Web Accessibility
As a partner with WebAIM, George Mason University is charged with developing a comprehensive model for institutional coordination and reform to support web accessibility. Useful resource for administrators and policymakers. Outlines a two and a half year implementation plan, which is broken up into three phases: http://www.webaim.org/articles/gmuplan
4. Suggested Web-AIM Standard Postsecondary Education Settings for Web Accessibility and Universality. The WebAIM guidelines are a public standard of Web accessibility. The Web-AIM Standard is a prototype standard suggested for use by postsecondary education settings. They are designed to facilitate easy adoption by organizations in need of a formal policy. Version 2.0, March 2000 (DRAFT) http://www.webaim.org/standards/webaim
This Standard is based on the guidelines published by the Web Accessibility Initiative (W.A.I.) of the World Wide Web Consortium (W3C). The same W.A.I. guidelines also serve as a basis for the technology standards of Section 508 of the Rehabilitation Act. The WebAIM standards incorporate all of the Priority 1 ("must do") and Priority 2 ("should do") standards of the W.A.I., along with a few elements of Priority 3 ("could do"). One additional recommendation from Section 508 of the Rehabilitation Act (which is not a part of the W.A.I. guidelines) was also incorporated. Section 508 requires a minimum adherence to priority 1 and 2 of the WCAG and parts of Priority 3. At a minimum, the higher education institution should meet the WCAG Priority 1 Standard.
-Develop a system by which to identify and maintain contact with individuals who place content on the web for the institution (e.g. registration process which allows individuals to be contacted by email).
-Develop a way to ensure accountability for the accessibility of each web page put out by the institution.
The Standard: In order for a Web site to be Web-AIM approved, all of its Web content must be accessible to individuals with or without disabilities.
The Purpose of the Web-AIM Standard
Students and faculty with disabilities at postsecondary education settings need full access to the content of the Web sites at their institutions. Without such access, they may miss out on important information, resources, and educational opportunities. In order for this to happen, Web developers at these institutions must know how to incorporate the principles of accessible design into their Web sites. This suggests the need for a common standard by which to judge a site's accessibility. The purpose of the Web-AIM guidelines is to establish this common standard.
No part or function of the Web content shall be excluded from being accessible to individuals with disabilities unless there is a compelling and legally justifiable reason to do so.
All of the information, resources, courses, and functionality of the institution's Web site(s) shall be accessible. This includes any Web "pages", and scripted or programmed content such as online registration programs, tutorials, email access, etc.
1. Individuals with disabilities must be able to access Web content either with standard technologies or with appropriate assistive technologies.
2. The Web content itself must be directly accessible to individuals with disabilities, rather than available only in alternative formats, such as paper, Braille, audio tapes, etc., unless there is a compelling and legally justifiable reason to do otherwise.
3. Content must adhere to the Web Content Accessibility Guidelines (WCAG) described by the Web Accessibility Initiative (W.A.I.) of the World Wide Web Consortium (W3C) such that the pages meet ALL Priority 1 and Priority 2 checkpoints as well as the following Priority 3 checkpoints: 4.2, 4.3, 5.5, 9.4, 13.6, 13.10, and 14.3.
To see the full explanation and expansion of the W.A.I., Web Content Accessibility Guidelines (WCAG) which are included in the WebAIM Standard, go to the next page. http://www.webaim.org/standards/webaim/wcag
4. Web-based instruction should allow for different learning styles and/or disabilities by utilizing more than one instructional approach and/or mode of presentation (e.g. text with graphics, audio or video) whenever possible¿especially if direct student-instructor interaction is minimal.
5. All Web-based instructional content, including any necessary accommodations, should be made available to students with disabilities at the same time that the content is made available to students without disabilities.
Individuals with disabilities
This includes individuals with impaired vision, hearing, voice, cognition, or musculoneural functions (e.g. seizures, impaired dexterity in the hands, limbs, and/or other parts of the body).
5. Another Example of a University Plan to Assure Accessible Websites
University of Washington http://www.washington.edu/computing/accessible/
Why Make Web Sites Accessible? Universities serve many people, including faculty, staff, students, and anyone in the state and beyond who is interested in the institution. As universities increasingly use information technologies (IT), our goal should be to make information and services that work for all who need them.
It is Easy to Do. Creating accessible Web sites is simple. Methods for creating accessible Web sites are now well documented, thanks to a strong movement in recent years to improve the accessibility of government services and public education. Also, Web publishing programs now include many features to help create accessible Web designs.
It Works for Everyone. Accessible design is good design for everyone. The same methods that make your site accessible will make your site more usable for all who visit.
It Is Good Strategy. Accessible design puts you in a good position to deliver your resources and services through other technologies such as cell phones, personal data assistants (PDAs) and voice access services, as well as assistive and adaptive technologies.
Avoid Hassles. Inaccessible Web sites are a liability and can lead to complaints, lawsuits, intervention by regulatory agencies, bad publicity, and expensive site redesigns.
Common Myths About Web Accessibility
How to be Accessible
How can you be sure your Web site is accessible? A good approach is to evaluate your site using the Web design guidelines developed by the Federal government's Section 508 initiative. They provide comprehensive guidance on how to make your site accessible.
Step One: Check your HTML
Be sure your HTML is error-free and complies with W3C standards. Most assistive and adaptive technologies are based on these standards. Error-free, well-formed, standards-compliant HTML is the foundation of an accessible Web site.
Step Two: Follow the Guidelines
HTML includes many features to help make your Web site accessible. Follow these guidelines on how to use those features. Click on the link at the beginning of each item for an explanation and examples.
Section 508 Guidelines (1194.22 Standards)
(a) A text equivalent for every non-text element shall be provided (e.g., via "alt", "longdesc", or in element content).
(b) Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation.
(c) Web pages shall be designed so that all information conveyed with color is also available without color, for example from context or markup.
(d) Documents shall be organized so they are readable without requiring an associated style sheet.
(e) Redundant text links shall be provided for each active region of a server-side image map.
(f) Client-side image maps shall be provided instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
(g) Row and column headers shall be identified for data tables.
(h) Markup shall be used to associate data cells and header cells for data tables that have two or more logical levels of row or column headers.
(i) Frames shall be titled with text that facilitates frame identification and navigation.
(j) Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.
(k) A text-only page, with equivalent information or functionality, shall be provided to make a Web site comply with the provisions of this part, when compliance cannot be accomplished in any other way. The content of the text-only page shall be updated whenever the primary page changes.
(l) When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.
(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 that complies with ¿1194.21(a) through (l).
(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.
(o) A method shall be provided that permits users to skip repetitive navigation links.
(p) When a timed response is required, the user shall be alerted and given sufficient time to indicate more time is required.
The following TUTORIALS provide clear explanations and plenty of examples.
Step Three: Evaluate Your Site
Now that you have an idea of the methods of accessible design, check some of your pages with an accessibility evaluation program. Several good ones are available on the Web.
- A-Prompt - University of Toronto's Web Accessibility Verifier. Accessibility Prompt is a tool kit to check for web page accessibility based on the WAI, Web Content Accessibility Guidelines 1.0.
The tool may be customized to check for different conformance levels, based on the Web Accessibility Initiative (WAI) Web Content Accessibility Guidelines 1.0. If an accessibility problem is detected, A-Prompt displays the necessary dialogs and guides the user to fix the problem. Many repetitive tasks are automated, such as the addition of ALT-text or the replacement of server-side image maps with client-side image maps.
- WAVE Accessibility Checker - Temple University. In addition to pointing out problems with your HTML, WAVE indicates the sequence in which parts of your page will be read.
- Bobby - CAST's utility to help you identify and repair significant barriers to access by individuals with disabilities.
Using Web Publishing Software
Vendor Accessibility Sites
To better understand how good Web design can help people deal with disabilities: