The Accessibility Testing Newsletter is a twice-monthly publication (second and fourth Fridays) intended to supplement training provided through the Accessible Apps project. It will contain information of use to both programmers and non-programmers. The Newsletter is sent automatically to AIS staff, and to other U-M personnel by request. Please send comments or questions to Jane Vincent, Assistive Technology Lead, .
Color contrast usually refers to the difference in color values between the text and background for either standard or bitmapped text. Guideline 1.4.3 of the Web Content Accessibility Guidelines (WCAG) states that the contrast between text and background should be at least 4.5:1, unless the text is large print (14 pt. or higher if bold and 18 pt. or higher if not bold), incidental, or part of a logo. Lighthouse International has an article on 'Effective Color Contrast' that provides good guidelines for ensuring that a page's color choices will meet or exceed WCAG.
Be aware that black text on a white background provides the highest level of contrast, but isn't necessarily the best choice. In fact, according to the UX Movement blog, black on white can make reading significantly harder for some people with learning disabilities. They suggest using light grey backgrounds and/or dark gray text instead.
Coming up in our 2/8 issue: a Refresher on flashing content
Does the law require my department to caption its videos?
Yes. As the University of Michigan continues to enhance its IT accessibility, it does so not only because providing access to all members and potential members of our community is the right thing to do and consistent with the University's core values, it is also consistent with Federal and State civil rights laws. The University complies with Section 504 of the Rehabilitation Act of 1973, the Americans with Disabilities Act (ADA) of 1990, and Michigan's Persons with Disabilities Civil Rights Act of 1976.
What are the specific requirements?
The University uses the Web Content Accessibility Guidelines 2.0 as a standard. WCAG guideline 1.2 stipulates that we must provide alternatives for time-based media, in this case video. In order to implement an accessible video, Success Criterion 1.2.2 (Level A) requires us to provide synchronized captions for non-live, web-based video (e.g., YouTube videos, locally hosted videos, etc.).
If I supply a transcript, does that mean I don't need to provide a caption?
You still need to supply a caption for your video. The ADA requirement is to give equivalent access to the deaf and hearing impaired. This means delivering to the deaf and hearing impaired a comparable experience to the one you're giving to those with normal hearing. Pointing deaf and hearing impaired users to a transcript or making them wait for captions to be produced and published on the site does not fulfil the spirit of this requirement. In addition, if you already have a transcript, most of the captioning task has been accomplished, and it is easy and inexpensive to produce the caption file.
If I supply captions, do I need to provide a transcript?
Could Helen Keller access your video? There are 40,000 people in the U.S. who are both deaf and blind. A transcript is the only way for them to access your video content. These users account for a sliver of the disabled population, but imagine the benefit of transcripts to them in accessing the huge volume of video content on the web. People without disabilities also appreciate transcripts because transcripts allow for the quick scanning of information. Not everyone wants to sit and passively absorb information for the full duration of a video.
Coming up in our 2/8 issue: Captioning, Part 2: undue hardship, YouTube, and in-house captioning
Note: Based on communication with Laurel Barnes, this discussion has been expanded and clarified. Thanks, Laurel!
Background: Any information presented in a solely visual format will be inaccessible to blind individuals. This includes information presented within a video; e.g., a demonstration of how to perform a procedure within a web page, or text that is not redundantly spoken. Success criterion 1.2.3. within the Web Content Accessibility Guidelines (WCAG) suggests two strategies for remediation:
As with text equivalents for graphics, it is seldom necessary to describe every visual detail of the video; however, details that are important for understanding or appreciating the video should be described. For instructive videos, make sure that all actions necessary to carry out procedures are described.
Example: A video has the following images and standard audio. Suggested descriptions are also included.
Standard audio: Music track with no speech.
Suggested description: 'A vision was born with a sole focus to address these needs.'
Explanation: The video presumably exists to convey the information presented in the text. If a blind user can't access this information, they're missing the point of the video. Therefore, the description should equal the text (rather like a text equivalent equaling the bitmapped text of a graphic). If there were other spoken information, it would be less important to convey this text in an audio description, but it should still be part of a transcript.
Standard audio: 'You can call 4-Help and speak to a specially trained service agent.' (Note that a screen reader user may interpret this as 'You can call for help and speak')
Suggested description: 'The 4-Help phone number is 734-764-4357.'
Explanation: Listeners may not know what 4-Help is, or may not be able to access the abbreviated number if they are off campus. It's therefore important for them to know the full number.
Standard audio: Music track with no speech
Suggested description: 'Type the name of your building into the Search field.'
Explanation: This is presumably an instruction that all users will need to follow to carry out the activity being taught in the video. Equivalent information therefore needs to be conveyed to both sighted and blind users.
Question: For each image below, what might be included in an audio description track or transcript to convey the full intent of the information?
1. (The phrase 'Minimize redundancy' is not included in the audio)
Answer: Add 'Minimize redundancy' if possible in an audio description (definitely if there is no other speech), and definitely in a transcript.
2. (The URL is not included in the audio)
Answer: Provide the URL in both the description and transcript so that individuals will know where to go for more information.
3. (Audio says, 'An official transcript bears the institutional seal. Here are some examples.')
Answer: Add 'Seal must be embossed or watermarked' to both the description and transcript. (Otherwise, the transcript may be rejected, forcing the student to unfairly take on more work than if they knew about this information beforehand.) Even better, in the original audio say something like, 'An official transcript bears the embossed or watermarked institutional seal.
Background: Imagine that you've just used your screen reader, speech input software, or other assistive technology to fill out most of a form. You're about to enter data into the final field and activate the send button.. when the site times out, erasing all your work. This is frustrating to any user, but because of the more time-intensive nature of assistive technology use, people with disabilities may find this to be an insurmountable barrier.
WCAG Guideline 2.2 indicates four options for extending timeouts:
The guideline also indicates two situations where it would be permissible to not permit timeout extensions:
Question: Which of the following would not require a timeout extension?
1. A ticket-selling site that gives everyone a twenty minute time limit between selecting and purchasing their seats
2. An online class that times out if it senses no activity for thirty minutes because the site designer just decided to set a time limit
3. A human resources site that times out after fifteen minutes for security reasons
4. 1 only
5. 1 and 3 only
The WAVE plugin for Firefox (available from http://wave.webaim.org/) is a free and popular accessibility checking tool. It puts icons next to features to show their basic accessibility compliance: red for errors, yellow for possible problems, green for compliance.
At the top of any results page, WAVE lists the total number of errors found. However, sometimes this number will not equal the number of visible red icons, so it is difficult to see where all the errors occur.
To expose all icons, go to the WAVE toolbar (below) and click on the 'Disable Styles' option.
The page will be presented in a linear text format, making it easy to see where all the icons are locate...
|Screenshot with styles active||Same page with styles disabled, showing an error icon that had been hidden|
Coming up in our 2/8 issue: New HTML5 feature for error checking
For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent