University of Michigan

Accessibility Testing Newsletter > 06.14.2013

All Newsletters

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, to the Web Accessibility Working Group (WAWG), and to other U-M personnel by request. Please send comments or questions to Jane Vincent, Assistive Technology Lead, jbvincen@umich.edu.

Refresher: Document Accessibility

The Internet often serves as a way to share documents in a variety of formats. Below is an overview of information about accessibility and different formats commonly used at U-M. Keep in mind, however, that HTML continues to have the most options to balance document complexity and accessibility, and should be kept in mind as an alternative format.

Microsoft Office documents (Word, PowerPoint, Excel): The Accessible Digital Office Document project tracks strategies for providing accessibility in different versions of Office (it does not yet include information about Office 2013). In addition, products in the 2010 version of Office include an accessibility checker; this is not exhaustive, but will catch several common issues. In all three products, this can be accessed by going to File-->Info-->Check for Issues-->Check Accessibility.

Google Drive: The accessibility of Google documents been unpredictable. At this point, the safest bet would be to provide a redundant version of the completed document in Word or HTML. It's usually fairly easy to download and save a copy of these documents in a Word format.

PDF: PDF remains a tricky format to make genuinely accessible, particularly if you are trying to retrofit a file that is already in PDF format. If you can convert the file to Word, or even better if you have access to a Word file that was used to generate the PDF, providing this file as an alternative format is usually the most reliable way to go.

If grant specifications or other commitments require you to produce accessible PDFs, I've found a program called CommonLook Office (formerly called PDF Accessibility Wizard) to be helpful and easy to use. CommonLook Office is a Word plugin that reviews your document and tells you what needs to be fixed. It can then be used to generate a PDF file with maximized accessibility. Two versions are available: Standard, which will handle basic documents, and Professional, which will handle documents that have forms and complex tables. If you only have a few documents to convert, CommonLook will do the work for you for a per-page charge, which may prove more cost-effective.

If you need to convert an existing PDF file, Adobe provides guidelines here. However, these are notoriously difficult to implement.

Coming up in our 6/28 issue, a Refresher on magnification technology

Problem of the Week: Audio Description

There are three WCAG guidelines that look pretty much alike:

1.2.3 Audio Description or Media Alternative (Prerecorded): An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such. (Level A)

1.2.5 Audio Description (Prerecorded): Audio description is provided for all prerecorded video content in synchronized media. (Level AA)

1.2.8 An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media. (Level AAA)

What's the difference between these?

Captioning is a text alternative for people who can't hear; audio description is a way of conveying visual information to people who can't see. Part of a transcript that provided both types of accommodation might look like this (with real-time audio description, the information in brackets would be added to the soundtrack):

Rick: Ilsa, I'm no good at being noble, but it doesn't take much to see that the problems of three little people don't amount to a hill of beans in this crazy world. Someday you'll understand that.

[Ilsa lowers her head and begins to cry]

Rick: Now, now...

[Rick places his hand under her chin and raises it so their eyes meet]

Rick: Here's looking at you kid.

If there's no information conveyed solely in visual form--either directly (such as information provided in visual text but not audio) or obliquely (such as meaningful gestures)--audio transcription is not needed.

1.2.3 (Level A) says that at a minimum, you must provide EITHER audio description OR a transcript. Both formats have advantages and disadvantages, so there is no automatic call on which is better; it depends on the nature and content of the video.

Here is a discussion of the three criteria, from the WCAG Standards website:

1.2.3, 1.2.5, and 1.2.8 overlap somewhat with each other. This is to give the author some choice at the minimum conformance level, and to provide additional requirements at higher levels. At Level A in Success Criterion 1.2.3, authors do have the choice of providing either an audio description or a full text alternative. If they wish to conform at Level AA, under Success Criterion 1.2.5 authors must provide an audio description - a requirement already met if they chose that alternative for 1.2.3, otherwise an additional requirement. At Level AAA under Success Criterion 1.2.8 they must provide an extended text description. This is an additional requirement if both 1.2.3 and 1.2.5 were met by providing an audio description only. If 1.2.3 was met, however, by providing a text description, and the 1.2.5 requirement for an audio description was met, then 1.2.8 does not add new requirements.

So in a nutshell:

1.2.3: If there is meaningful visual-only content, provide either audio description or a transcript.

1.2.5: If you provided only a transcript to meet 1.2.3, also provide audio description.

1.2.8: If you provided only audio description to meet 1.2.3, also provide a transcript.

Coming up in our 6/28 issue: Whatever happened to access keys?

Answer to 5/24 Quiz Question: Text Transcripts, Part 1: Access to Audio

Background: WCAG Success Criterion 1.2.1 cites a transcript as one way to provide access to information that is only presented in audio or visual form. While this transcript should include all dialogue, it should also indicate where meaningful non-text sounds occur--animal noises, music, etc.--particularly if they would not be inferred from the visual. (The difference between captions and transcripts is that captions are time-synced to a video, while transcripts are not. The only option for audio-only formats, such as podcasts, are transcripts.)

The Captioning Key, a standard guide to writing captions, devotes three pages to describing sounds. Although this guide does not explicitly cover transcripts, much of the information is still relevant, including (but not limited to) the following:

  • Provide a description in brackets including the source of the sound if not obvious from the visual (e.g., [dog barking], [Fred coughs]).

  • Italicize sound effects that occur offscreen

  • Use elipses to indicate a pause between sounds, e.g.,

Examples:

1. The ending of Casablanca (video link).

Information that could be added to a transcript includes the following:

2. The Fish Slapping Dance (video link).

Information that could be added to a transcript includes the following:

3. Tongue Tied (video link).

Information that could be added to a transcript includes the following:

Question: How would you caption the non-dialog sound in this video of an interrupted University of Michigan class?

Answer: Useful non-dialog captions might include the following:

6/14 Quiz Question: Text Transcripts, Part 2: Access to Visual Elements

Background: WCAG Success Criterion 1.2.1 cites a transcript as one way to provide access to information that is only presented in audio or visual form. If significant information is only presented visually, audio description is a way to convey this information to individuals who have visual disabilities.

The American Council of the Blind (ACB) has published an evolving set of guidelines for audio description. The summary for these guidelines includes principles such as the following:

If you wish to add captioning or audio description to the actual video, the National Center for Accessible Media (NCAM) lists a wide range of useful resources.

Examples:

1) Media Access Australia provided an audio description transcript of a hunting scene from Hunger Games:

Signs on a tall wire fence read 'District boundary: no access beyond this point' and 'high voltage'. Katnis steps through a gap in the wires and into the woods beyond. She glances around before reaching into the hollow of a fallen tree. She draws out a wooden bow. From another tree she plucks out a sheath of arrows and straps it over her shoulder.

Katnis makes her way through thick, green vegetation. Bow and arrow at the ready, she walks over a fallen tree suspended over the forest floor. She pauses, her gaze locked on a deer in the distance. Leaning against a tree trunk, she aims the bow and arrow. The deer sniffs the air and moves out of sight.

2) The full ACB document includes a sample transcript from a video called 'Storm Reading.' Below is the section of the transcript from the section of video shown at the Audio Description Associates website (scroll to the next to last video)

NOTE: Cues/original script material in BOLD; descriptions preceded by ">>."

>>Watercolor patches on a white screen -- from the left, a deep orange brush
>>stroke, a thin blue stroke, bordering an area of yellow at the right, with
>>white at the bottom.

>>Against this bright background, a hand in silhouette emerges from the
>>bottom. It disappears. Now, the shadow of a man's head in profile.
>>Unfolding his body slowly, Neil Marcus rises. He steadies himself, gaining
>>the control needed to stand upright. His full silhouette rises upward -
>>his legs form an upside-down V shape in black with his right foot pointed in,
>>toward his left.

>>More of the background images come into view -- at left, a dark blue; at the
>>top, on the right, a rich green.

>>Neil's left arm, his hand clenched in a fist, bursts upward -- his right arm is
>>thrust across his body, pointing to his left. They remain posed, still, in
>>silhouette against the bright watercolor images, as titles appear: Access
>>Theater's Storm Reading, a drawing of a dense cloud at top, a thunderbolt
>>striking the "O" in Storm. The audience area lights fade to black.

>>Now, Neil, in a motorized wheelchair, sports a full but neatly trimmed beard,
>>black hair, and wears a blue turtleneck and brown slacks -- in the center of a
>>small stage in front of a light blue backdrop.

NEIL: People are watching me. They're watching me all the time...

>>Stage lights rise to full revealing large blue-lit panels circling the stage area.
>>Katie, a tall brunette in a flowing lavender dress, joins Neil from the right
>>and signs as he speaks.

3) This Youtube link is a video excerpt from Hamlet. Note that the audio description only occurs when there is no dialogue.

Question: How would you create an audio description transcript for the visual information in the Explore Ann Arbor video? (Again, no prizes this week, but if you send me a transcript I'll be happy to review it.)

Evaluation Tool Tip: Read & Write Gold Update

U-M is currently in the process of upgrading Read & Write Gold to version 11 for availability on all Sites Windows computers. Read & Write is a software package with a variety of tools likely to be of use to people with learning disabilities.

Among other innovations, Read & Write has the only text-to-speech capability (to my knowledge) that will work with Google Docs running in Chrome. Formerly, this was available as a Chrome plugin, but other toolbar functions did not work in Chrome, forcing users to switch between Internet Explorer for browsing and Chrome for working with Docs. In version 11, the Docs reader is part of the Read & Write toolbar, and many critical toolbar functions now work with Chrome as well as Firefox.

Because Read & Write requires mouse use, it is not appropriate for blind users. However, it is a powerful solution for individuals who benefit from simultaneously hearing and seeing text.

TextHelp, which makes Read & Write, has indicated that they do not plan to upgrade their Mac version until next year. Mac users can still install and use the Read & Write for Google Docs extension from the Chrome Web store.

Coming up in our 6/28 issue: Using Amara to create captions and transcripts

For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent, John Cady