University of Michigan

Accessibility Testing Newsletter > 11.26.2012

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

Refresher: Screen Readers vs. Text-to-Speech Programs

Most individuals who cannot effectively view information on a monitor use screen readers to render this information in an audio format. However, people without visual disabilities may also benefit from hearing onscreen information. Some people with learning disabilities benefit from simultaneous audio and visual access to text, and audio output can be a great proofreading aid for people with and without disabilities.

The main difference between screen readers for blind individuals and text-to-speech programs for sighted users is that text-to-speech programs generally speak only visible information, while screen readers will speak information that is not visible--e.g., hidden links and text descriptions of graphics. Screen readers will also read summary information, such as the number of links on a page.

Many WCAG 2.0 web accessibility guidelines, especially at Level A (minimal conformance), cover the inclusion of code designed specifically to enhance compatibility with screen readers. Although this code usually does not affect text-to-speech programs, that doesn't mean their users don't face accessibility issues as well. For example, like screen readers, most current text-to-speech programs cannot read bitmapped text.

Coming up in our 12/14 issue: a Refresher on how people might use keyboard commands as a substitute for the mouse.

Problem of the Week: CAPTCHAs

I've been told to add a CAPTCHA to the form section of a site that I'm designing, since it will have a lot of visibility and the client is expecting many spambot hits. Can you recommend a CAPTCHA that will be both effective and accessible?

Answer: Many developers are working on the issue of developing an accessible CAPTCHA. A common problem is that current solutions designed to promote accessibility for one group may introduce problems for others--including contingents of people who are non-disabled. For example:

Screenshot of reCAPTCHA with audio options in addition to the standard distorted CAPTCHA text.

An alternative strategy is to eliminate interactive CAPTCHAs and instead use PHP code to automatically examine submissions and eliminate those likely to be spam. WebAIM has an article on non-interactive spam-blocking techniques; they claim a near-perfect elimination of spam without impacting form accessibility or usability.

Coming up in our 12/14 issue: Do layout tables cause accessibility problems?

Answer to 11/9 Quiz Question:

Background: WCAG Guideline 1.4.1. states that information conveyed via color needs to have at least one redundant visual means of conveying the information. This redundant strategy can be text, shape, or any other indicator that does not rely on color.

Example: Planview has the following on its Authorized Work: Project View page:

A list of items where green circles are used to indicate project work and blue circles are used to indicate support ticket work.

Question: Is the use of colored circles compliant with Guideline 1.4.1? If not, what could be done to bring it into compliance? Answer: The only distinction between the blue and green circles is their color; therefore, their use is not compliant. One strategy to fix this would be to use different shapes; e.g., 'The green circle will display next to project work; the blue square will display next to Support Ticket work.' Another would be to make the circles large enough to put a letter inside; the circle for project work could be marked with a P while the circle for Support Ticket work could be marked with an S.

11/26 Quiz Question

Background: Since there is no auditory equivalent of a glance, screen reader users are often dependent on HTML markup to provide clues about the structure of a given page. A popular strategy involves using heading tags <h1> through <h6> to convey a sense of information hierarchy within the page. Indeed, a 2012 survey of screen reader users found that nearly half found that navigating a page using heading tags was 'very useful,' and another 35% found it 'somewhat useful.'

For heading tag markup to be meaningful, the following best practices are recommended:

Example: When the WAVE accessibility checker is used on the U-M Office of Technology Transfer home page, it shows that the only two headings on the page are the <h2> associated with the picture on the left, and the <h3> for 'News and Events' on the right.

Screenshot of TechTransfer page with one <h2> heading modifying a graphic and one <h3> heading for 'News and Events.

Question: What two best practices could be invoked to make the heading markup more meaningful?

Evaluation Tool Tip: New NVDA keyboard overlay

If you use the free NVDA screen reader to test for accessibility, you may find it frustrating to try to remember or find specific commands. To help sighted testers, an accessibility resource called AccessIQ has developed a free pair of keyboard overlays –one for desktop computers and one for laptops--that can be downloaded, printed, and used for reference.

Coming up in our 12/14 issue: Checking HTML code for validity

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