390 likes | 712 Views
Web Accessibility. Writing for the Web. Contents. Accessibility background Accessibility guidelines References. Accessibility: Background. Intended Audience of Accessibility Initiatives. Users unable to: See, hear, move. Process some types of information.
E N D
Web Accessibility Writing for the Web The Internet Writer’s Handbook 2/e
Contents • Accessibility background • Accessibility guidelines • References
Accessibility: Background The Internet Writer’s Handbook 2/e
Intended Audience of Accessibility Initiatives Users unable to: • See, hear, move. • Process some types of information. • Read or understand text or language. • Use a keyboard or mouse. • Use a large screen. • Have fast Internet connection. • Have new browser.
Web Accessibility Initiative of the World Wide Web Consortium • Developed accessibility guidelines.
W3C WAI Standards 1. Provide equivalent alternatives to auditory and visual content. 2. Don't rely on color alone. 3. Use markup and style sheets properly. 4. Clarify natural language usage.
W3C WAI Standards 5. Create tables that transform gracefully. 6. Ensure that pages featuring newer technologies transform gracefully. 7. Ensure user control of time-sensitive content changes. 8. Ensure direct accessibility of embedded user interfaces. 9. Design for device-independence. 10. Use interim solutions.
W3C WAI Standards 11. Use W3C technologies and guidelines. 12. Provide context and orientation information. 13. Provide clear navigation mechanisms. 14. Ensure that documents are clear and simple.
W3C WAI Priority 1 • A Web content developer must satisfy this checkpoint. Otherwise, one or more groups will find it impossible to access information in the document. • Satisfying this checkpoint is a basic requirement for some groups to be able to use Web documents.
W3C WAI Priority 2 • A Web content developer should satisfy this checkpoint. Otherwise, one or more groups will find it difficult to access information in the document. • Satisfying this checkpoint will remove significant barriers to accessing Web documents.
W3C WAI Priority 3 • A Web content developer may address this checkpoint. Otherwise, one or more groups will find it somewhat difficult to access information in the document. • Satisfying this checkpoint will improve access to Web documents.
Accessibility Guidelines The Internet Writer’s Handbook 2/e
1. Provide equivalent alternatives to auditory and visual content • Images • Graphical representations of text (including symbols) • Image map regions • Animations (e.G., Animated gifs) • Applets and programmatic objects • ASCII art • Frames • Scripts
1. Provide equivalent alternatives to auditory and visual content • Images used as list bullets • Spacers • Graphical buttons • Sounds (played with or without user Interaction) • Stand-alone audio files • Audio tracks of video • Video
1. Provide equivalent alternatives to auditory and visual content • Provide redundant text links for each active region of a server-side image map. • Provide an auditory description of the important information of the visual track of a multimedia presentation. • For any time-based multimedia presentation, synchronize equivalent alternatives (e.g., captions or auditory descriptions of the visual track) with the presentation.
2. Don't rely on color alone • Ensure that all information conveyed with color is also available without color (e.g., from context or markup).
3. Use markup and style sheets properly • Not priority 1
4. Clarify natural language usage • Clearly identify changes in the natural language of a document's text and any text equivalents (e.g., captions).
5. Create tables that transform gracefully • For data tables, identify row and column headers. • For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.
6. Ensure that pages featuring new technologies transform gracefully • Organize documents so they may be read without style sheets. • Ensure that equivalents for dynamic content are updated when the dynamic content changes.
6. Ensure that pages featuring new technologies transform gracefully • 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.
7. Ensure user control of time-sensitive content changes • Until user agents allow users to control flickering, avoid causing the screen to flicker.
8. Ensure direct accessibility of embedded user interfaces • Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
9. Design for device-independence • Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape.
10. Use interim solutions • Not Priority 1
11. Use W3C technologies and guidelines • Not Priority 1
12. Provide context and orientation information • Title each frame to facilitate frame identification and navigation.
13. Provide clear navigation mechanisms • Not Priority 1
14. Ensure that documents are clear and simple • Use the clearest and simplest language appropriate for a site's content.
Tools for Evaluating Accessibility The Internet Writer’s Handbook 2/e
Bobby • Web-based public service offered by the Center for Applied Special Technology (CAST). • Analyzes Web pages for their accessibility to people with disabilities and compatibility with various browsers. • http://www.www.cast.org/bobby/
The Wave • Tool to help determine your page's accessibility by presenting the "linearized" reading order, ALT text for images and image map areas, and the applet alternatives. • http://www.temple.edu/inst_disabilities/piat/wave/
TOM, the Text-Only Maker • Developed at developed at the National Center for Supercomputing Applications (NCSA). • Converts graphical Web pages into text-only pages or text and graphics Web pages. • http://www..eot.org/TTF/Access/tom.html
W3C • Checks HTML documents for conformance to W3C HTML and XHTML recommendations and other HTML standards. • http://validator.w3.org/
References The Internet Writer’s Handbook 2/e
References • W3C WAI www.w3c.org/wai • Access Adobe access.adobe.com • IBM Accessibility Center www-3.ibm.com/able/overview.html • Microsoft Accessibility www.microsoft.com/enable
References • Center for Applied Special Technology (CAST) www.cast.org • Do-IT www.washington.edu/doit • WebABLE www.webable.com