Usability Testing for Accessible Web Sites (Part 4)

by Anne Savitsky-Blondin

May 2006

On Wednesday, May 10, 2006, Fidelity Investments hosted a Boston-IA meeting featuring Marguerite Bergel, Ann Chadwick-Dias, and Alison Savery of the eBusiness Design group describing the work being done at Fidelity to test Web site usability with blind and low vision users.

In the third presentation of the evening, Marguerite Bergel and Ann Chadwick-Dias reported on the results of preliminary testing that Fidelity has been performing on Flash accessibility by users of the JAWS screen reader. (Part 4 of 4)

This article is divided into the following sections:

• Introduction
• Presentation 1: JAWS Navigation Study
• Presentation 2: Job Opportunities@Fidelity Study
• Presentation 3: Preliminary Research on Understanding the JAWS User Experience of Flash

Presentation 3: Preliminary Research on Understanding the JAWS User Experience of Flash

Note: JAWS dropped Flash support in versions 5.0, 5.1, and 6.0, but resumed support with versions 6.1 and higher. This information was not available to the team prior to the study and they used version 6.0. They reported that lacking support for Flash greatly affected the user experience.

Back to top

User Perceptions

The team reported the following user perceptions about interactions with Flash by screen reader users:

• Users reported unfamiliarity or negative experiences with Flash: Most thought it was "eye candy" and "a way to hook people visually". Many were not sure what Flash did or could grasp its benefits. Those who felt they knew what Flash was tried to avoid it.
• Users did not expect sites or applications to be built in Flash: Most expected Flash components to be demos or multimedia movies, not whole web sites, applications, or interactive components. Conceptually, users expected movies to be movies.
• Most Flash components appeared as buttons: List boxes, fields, and links all appeared as buttons. Link lists produced audio indicating that no links were found, so users assumed there was very little content on the page. The non-standard behavior of Flash was confusing to users who expected buttons to behave like HTML.
• Basic access produced confusing messages: Users were unsure whether they were in a new window or4 in the same window, and they could not figure out how to get back to a parent page. Sometimes the Enter key or space bar worked, and sometimes both or neither— in the same application and for the same user. People were confused by hearing "Movie start" or "Movie end," thinking they had moved past the Flash application. Finally, the screen reader did not always recognize the movie.

Back to top

Design Recommendations

The design team offered the following suggestions for those considering using Flash for their Web site redesigns, especially where accessibility issues are concerned:

• Use Flash when a clear benefit exists.
• Clearly label all buttons and components.
• Add descriptions or summaries to Flash components, indicating whether they are multimedia, forms, or sites.
• Ensure keyboard accessibility.
• Provide keyboard shortcuts for primary functions such as player controls.
• Make controls larger and provide higher contrast.
• Make text larger and provide higher contrast.
• Provide tool tips.
• Provide obvious scalability options.
• Launch demos in separate browser windows.
• Add invisible text that tells users how to navigate the application (for example, add an accessibility link to Flash demos or sites).
• If content cannot be made reasonably accessible, provide alternatives (for example, a transcript).
• Consider hiding unimportant Flash content (for example, ads).
• Detect screen readers through the use of scripts.

Back to top

End of Article

Back to top

© 2006 Anne Savitsky-Blondin and P.J. Gardner. All rights reserved.

Anne Savitsky-Blondin is an information architect specializing in content development for intranets and training.