Wiki Resources/Accessibility

From Wikiversity
Jump to navigation Jump to search

Home | Learning Theories | Instructional Design & eAuthoring | ePortfolio | Storyboard | Wiki Analysis | Communication Tools | Resources Analysis | Group Work | Teaching Philosophy | Accessibility | Glossary


human accessibility emblem

Introduction[edit | edit source]

Products and services, including documentation, should be easy for everyone to use. Content can also be created to maximize accessibility for people with disabilities. For example, printed documentation should be made available in accessible formats for users who have difficulty handling or reading conventionally printed materials. A format most commonly used is XML. HTML is also acceptable if it follows accessible design guidelines.

Learning Outcomes[edit | edit source]

At the end of this chapter the learner will be able to:

  1. Understand the importance of accessibility in your learning object.
  2. Understand which the items you have to provide to became your learning object accessible.
  3. Understand how to evaluate your learning object to fill with the accessibility norms.


We would appreciate if you give us your contribution in this chapter. Also, if you have any query, suggestion or feedback, don't hesitate to contact us sending a message to our email:
wikiresourcesgroup@gmail.com


Accessibility Appendix[edit | edit source]

In both online and printed documentation, every product should include an appendix describing features and services that can aid persons with dis­abilities. Each appendix describes accessibility options available in the product or from other sources, such as recording for the blind. This appendix makes it easier for users with disabilities to use products, raises public awareness of the available options, and demonstrates a company’s commitment in this area. Include this appendix as a Help topic and in the printed book most likely to be the first one opened.

Accessible Web Page[edit | edit source]

Keep in mind that not only do people with various kinds of disabilities need information from your Web site, but so do people using various kinds of browsers, who have graphics turned off, or who may not have the latest technical wiz­ardry. The guidelines given here are brief reminders. You can find more details about the rationale for these guidelines and some ways to accomplish them on these web sites:
  1. Web Accessibility Initiative
  2. MSDN Accessibility
  3. Center for Information Technology Accommodation

Perceivable[edit | edit source]

1. Provide alternatives text for non-text content.
Consider what the page looks like or sounds like when the images are not shown. Then write for each image an alt text that best works as a replacement.
If the image is purely decoration then use an empty alt tag.
For short simple descriptions of less than 50 characters, for example 'pie chart showing 80% of sales are overseas' enclose the text in quotation marks.
For images that are merely described, for example, 'this is a pie chart' enclose the text in square brackets to delineate it from the rest of the general text.
For images which need to be described in detail you will need to link the alt tag to a separate web page describing this. Some types of links often work best if the link text is accompanied with an image.
Instead of using two links pointing to the same destination, it is best to make them one link, using markup like the following: <a href="address"><img src="imagefile" alt=""> linktext</a>.
An important reason for using a single link instead of two links is that when the user tabs from one link to another, redundant links make the use less convenient. Moreover, if there are two links, the question easily arises whether they really point to the same resources. :Note that the alt attribute should have an empty value, since the image is "redundant".
2. Provide captions and alternatives for audio and video content:
Make content adaptable; and make it available to assistive technologies.
Use sufficient contrast to make things easy to see and hear: do not use colour coding alone.
Use additional cues, such as textual annotations or the underlines.
Alternatively, use patterns as well as colours to indicate different types of information in charts and graphs.
Avoid hard-to-read colour combinations, such as red and green or light green and white. People with some types of colorblindness may have difficulty seeing the differences between the colors.
Avoid screened art. Contrasting black and white is easiest to read. Especially avoid text on a screened background, which is difficult to see and for a machine to scan. For the same reason, avoid shaded backgrounds and watermarks or other images behind text.
Avoid printing text outside a rectangular grid. People with low vision may have difficulty seeing text outside of an established grid. Try to keep text in a uniform space for both visibility and scannability.

Operable[edit | edit source]

  1. Make all functionality keyboard accessible
  2. Give users time to read and use content
  3. Do not use content that causes siezures
  4. Help users navigate and find content

Accessible Writing[edit | edit source]

To enhance the accessibility of Web pages for people who use screen readers, follow these guidelines: ~Always provide alt text for nontext elements, including graphics, audio, and video. For simple elements, a brief but accurate description is enough. Use an asterisk (*) or the word “bullet” for bullets, not a description such as “little blue ball.” Leave blank information about invisible placeholders. For more complex elements, provide a link to a separate page with more details.

  1. Provide text links in addition to image maps.
  2. Write link text that is meaningful but brief. Do not use phrases such as click here. Use links that can stand alone in a list. Use the <TITLE> tag to distinguish links and names in image maps from ambiguous or duplicate text.
  3. Make link text distinct. Use redundant visual cues, such as both colour and under-line, so colour blind users can identify link text.
  4. Plan links and image map links so that navigation with the TAB key moves from left to right and top to bottom, not randomly.
  5. If you use frames, provide alternate pages without them.
  6. If you use tables, provide alternate pages without them. Make sure that tables make sense when read from left to right, top to bottom. Note that Internet Explorer versions 3 and 4 have some different and strict requirements.
  7. Provide closed captions, transcripts, or descriptions of audio content.
  8. Avoid using scrolling marquees. Accessible Writing Many of the following suggestions for maximizing accessibility also help make documentation clearer and more useful for everyone:
  9. Provide clear, concise descriptions of the product and initial setup, including a section or card that gets the user up and running with the basic features.
  10. Keep the number of steps in a procedure short. Individuals with cognitive impair­ments may have difficulty following multistep procedures. Keep the steps simple, and keep the reader oriented.
  11. Keep sentence structure simple. Try to limit most sentences to one clause. Indi­viduals with language difficulties and those who speak English as a second lan­guage, as well as some people who are deaf or hard of hearing, may have difficulty understanding long, complicated sentences.
  12. Provide descriptions that do not require pictures, or that include both pictures and writing. Using only diagrams causes difficulty transcribing to other media. To test whether the writing is effective, try removing, one at a time, first the words and then the pictures. With only one method, can you still figure out what to do?
  13. Avoid using directional terms (left, right, up, down) as the only clue to location. Individuals with cognitive impairments might have difficulty interpreting them, as do blind users relying on screen-reading software. A directional term is acceptable if another indication of location, such as in the Save As dialog box, on the

Standard toolbar, or in the title bar, is also included. Directional terms are also acceptable when a sighted user with dyslexia can clearly see a change in the interface as the result of an action, such as a change in the right pane when an option in the left pane is clicked.

  1. Emphasize key information and put it near the beginning of the text. Use bullets or headings to additionally emphasize important points.
  2. Keep paragraphs short or otherwise create small sections or text groupings.
  3. In product documentation, document all keyboard shortcuts. A two-column format, in which the first column describes the user task and the second column describes the shortcut, is best. That way, users with screen readers can hear the task before they hear the keyboard shortcut. #Organize keyboard shortcuts in task groupings so related shortcuts appear close together.

Accessible Graphics and Design[edit | edit source]

It is possible to work within the requirements of standard design templates to make written content as visually accessible as possible. For example, use short paragraphs and break up long passages of text with subheadings. Follow these guidelines for visually accessible documents:

  1. Do not use colour coding alone. Use additional cues, such as textual annotations or the underlines. Alternatively, use patterns as well as colours to indicate different types of information in charts and graphs.
  2. Avoid hard-to-read colour combinations, such as red and green or light green and white. People with some types of colorblindness may have difficulty seeing the differences between the colours.
  3. Avoid screened art. Contrasting black and white is easiest to read. Especially avoid text on a screened background, which is difficult to see and for a machine to scan. For the same reason, avoid shaded backgrounds and watermarks or other images behind text.
  4. Avoid printing text outside a rectangular grid. People with low vision may have difficulty seeing text outside of an established grid. Try to keep text in a uniform space for both visibility and scannability.

References[edit | edit source]

  1. Microsoft (2009) Accessibility web site: http://www.microsoft.com/enable
  2. Microsoft (2009) MSDN Developers Accessibility web site: http://msdn.microsoft.com/default.aspx
  3. The Center for Information Technology Accommodation (CITA) of the U.S. General Services Administration: http://www.gsa.gov/Portal/gsa/ep/home.do?tabId=0
  4. Section 508 of the Rehabilitation Act of 1998: http://www.section508.gov/index.cfm
  5. Trace Research and Development Center at the University of Wisconsin: http://trace.wisc.edu
  6. Microsoft Manual of Style for Technical Publications (2004). 3rd ed. Microsoft Corporation Editorial Style Board.