University of Michigan

Accessibility Testing Newsletter > 05.24.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,

Refresher: Heading Markup

A key accessibility concept for screen reader users is providing ways that users can access a summary of page content. Sighted users are able to glance at a page and very quickly get a feel for its purpose. Since there is no auditory equivalent of a glance, screen reader users often navigate through just the page headings to get a feel for the page hierarchy. In fact, in the most recent WebAIM survey of screen reader users, over 80% of respondents found heading markup to be 'very' or 'somewhat' useful.

Generally accepted rules of thumb for creating appropriate heading markup are the following:

Correct Example:

<h1> Livingston Awards Announced</h1>
<p>ANN ARBOR, Mich.--The new Livingston Award winners were announced today.
<h2>Names of Winners</h2> <p>
Winners for 2011 are:
<h3> Local Reporting</h3>
Andrew McLemore
<h3> National Reporting</h3>
<p>Olga Pierce

Incorrect Example:

<h3> Livingston Awards Announced</h3>
<p>ANN ARBOR, Mich.--The new Livingston Award winners were announced today.
<h1>Names of Winners</h1> <p>
Winners for 2011 are:
<h4> Local Reporting</h4>
Andrew McLemore
<h4> National Reporting</h4>
<p>Olga Pierce

Coming up in our 6/14 issue, a Refresher that provides an overview of document accessibility

Problem of the Week: Coding for Speech Input Compatibility

I've recently been made aware that accessibility isn't just about working with screen readers; it's also about compatibility with other assistive technologies, such as Dragon NaturallySpeaking speech input software. What do I need to know so that Dragon users can access my website?

Excellent question. The most common strategy is to provide an 'Accessibility' link to a page with this information, preferably near the top of the page (perhaps right after a skip-nav link). The page should include as much of the following information as possible:

First off, it's important to remember that Dragon can do two things. It substitutes for the keyboard by allowing dictation of text into form fields and other text areas, and it substitutes for the mouse by allowing use of spoken commands to perform interactive functions, such as opening a link.

Nuance, the current manufacturer of Dragon, has published a set of Guidelines for Speech-Accessible HTML for Dragon NaturallySpeaking and Dragon Medical that provides explicit guidance on compatibility with both dictation and mouse emulation functions. Their guidelines include the following:

Information is also included on how to create specific types of elements, such as menus and buttons.

Coming up in our 6/14 issue: What's the difference among WCAG Level A, AA, and AAA guidelines related to audio description?

5/10 Quiz Question: Troubleshooting

Background: Below are examples of offbeat electronic accessibility problems. Your challenge will be to come up with one or more potential fixes, and email your ideas to Jane (

Problem 1: A user with low vision opened the last Newsletter in Google Mail and finds that it contains several very wide graphics. The user reported that, 'Google Mail in the Chrome browser picks [the width of the graphic] as the width of the text-display, however my monitor is not that wide. Therefore, for each line, I need to scroll right and left in order to see the whole thing.' How can this be fixed so that the user doesn't need to scroll?

Solution: Edie Andrew asked, 'Would keeping the image [to] 600 [pixels wide] or less work?' Edie, that's how we solved the problem.

Problem 2: A client insists that you use #B36F0B as a site background color. You test it for color contrast with the two extremes of text color: white (#FFFFFF) and black (#000000). White fails by a significant, although not huge, margin: it has a contrast ratio of 4.04:1 for regular size text, where the passing ratio is 4.5:1. Black passes with a contrast ratio of 5.2:1, but several users complain that it's hard to read. What would you suggest?

Image with brown background, 'Welcome to my gingerbread house!' in white text, 'Welcome to my gingerbread house!' in black text

Solution: Gonzalo Silverio wins for his initial suggestion: 'Put a contract out on the client.'
His decidedly more legal solution was to bump the text size up to large scale (at least 18 pt., or at least 14 pt. bold):

Image with brown background, 'Have some pumpkin pie' in large black text, 'Have some pumpkin pie' in smaller white text

Problem 3: A home web page is missing an <h1> heading, which is important for letting blind users know the main purpose of the page they are on. There is no body text to which the <h1> can be assigned. However, the page has a logo and a menu bar. How might <h1> information be appropriately included?

Solution: Patty Bradley was the first to suggest using CSS to control the formatting for an invisible <h1>. She'd obviously read the December 14, 2012 newsletter, which stated:

'But wait,' you might say, ' doesn't the logo have the <h1> on this page?' True, but because it is not coded as a heading, it conveys no semantic meaning to a screen reader. In fact, functionally, the logo is a link to the home page. Because adding a visible <h1> heading would clutter the page for sighted users, the heading should be placed before the main content in the code order, but positioned off-page with CSS to hide it from sighted users. (Do not use visibility: hidden or display:none to hide the text as these will hide the text from screen readers as well.)....An image shouldn't be coded as a heading.

Prizes will go out to the winners next week. Thanks for playing!

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:

In the next newsletter issue, we will discuss how to incorporate description of visual information into a transcript.


Note: These are intended as illustrative captions and are not necessarily complete for each example.

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 the video at this video of an interrupted University of Michigan class? (No prizes this week, but if you send me a transcript I'll be happy to comment on it.)

Evaluation Tool Tip: How Google's ChromeVox screen reader differs from JAWS and NVDA By Scott Williams

In an effort to improve the accessibility of Google Apps, Google has produced its own screen reader, ChromeVox. Google maintains that its web applications go beyond the boundaries of conventional web pages and that the leading screen readers are incapable of interacting effectively with web pages that behave more like applications than like traditional static web pages. Therefore, inventing a new screen reader was deemed necessary.

JAWS is the most prevalent screen reader on the market. It has a long track record and a feature-rich interface designed to get around inaccessible websites. It is also notoriously expensive at $900 and up. Well before ChromeVox came on the scene, a free, open source Windows-based screen reader, NVDA, was developed and introduced as an alternative to JAWS. With a small crew of developers that was versed in the needs and preferences of the screen reader community, NVDA has become a viable alternative to JAWS and boasts a burgeoning user base.

Why has NVDA become so successful? For starters, NVDA's interface made use of the pre-existing JAWS shortcut keys. Users didn't need to learn an entirely new set of commands, making for a shallow learning curve. Like JAWS, NVDA employs 'first-key navigation,' allowing users to conveniently press single keys to navigate a page (e.g., H for next heading, TAB for next link or control, etc.). Also, NVDA complied with existing web standards so that it worked well with websites that also adhered to standards. Last, but not least, NVDA is both free and high-quality. A leading screen reader expert and long-time JAWS user commented to me that if not for JAWS's unique 'page-info' functionality, she would switch to NVDA as her go-to browser.

In contrast to NVDA, ChromeVox, even though it is a free add-on for the Chrome browser and is part of the standard install for Chrome OS, has had limited adoption. There are a number of possible reasons for this:

While ChromeVox employs some novel approaches that could be useful if refined, at this point it is difficult to master, particularly for experienced screen reader users. This is likely to affect its widespread adoption. U-M is continuing to work with Google to encourage increased support for third-party screen readers in addition to development of ChromeVox.

Coming up in our 6/14 issue: Updates on implementation of Read & Write Gold software at U-M

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