Best Practices for Accessible Flash Design: Part 1 | 2
  [next] |
Best Practices for Accessible Flash Design: Part 1
By Bob Regan
This article is designed to establish a basic framework with which to approach accessible design in Macromedia Flash. Given the infinite variety of controls, objects and applications possible in Flash, it is not feasible to construct a finite and fixed set of rules for accessible design. The central tenet of accessible design is to test, test, and test again. This also presents the greatest challenge of accessible design. In order to build accessible Flash content, designers need to develop at least a limited understanding of a screen reader and other assistive technologies.
This article includes the following topics:
|
The first section, Understanding Accessibility in Flash, provides a brief overview of Flash accessibility and the specific challenges it presents as well as a recommended methodology for designing accessible Flash content. This section also presents a limited number of use cases to help designers who may be unfamiliar with accessibility to understand the specific strategies employed by people with disabilities.
The second section, defining user requirements, presents a limited number of use cases. The use cases may be implemented as personas in the design process with an explanation of issues, challenges, techniques and tools used in each case.
The third section, Accessibility Best Practices walks through a series of recommendations for accessible design in Flash. These are:
|
Understanding Accessibility in Flash
Web accessibility is the ability of any user, regardless of disability to access the same content and information on the Internet. For the Flash designer and developer, the challenge of is to remove the obstacles that prevent users with disabilities from effectively using a site or application.
The range of disabilities is broad and difficult to categorize; however, it is important to have some sense of the scope of the issue. A 1997 report by the U.S. Census Bureau categorizes 19.6 percent of the United States population as having some sort of disability. Within that group are individuals with:
|
In order to create accessible Flash content, it is important to consider the use cases for people with disabilities. Users with disabilities frequently rely on hardware and software to access web content. These tools, known as assistive technologies, can range from screen readers to touch screens or head pointers which are used to access a keyboard. Screen readers enable users to hear, rather than read, the contents of a web page. The specific use cases for people with disabilities will be discussed in greater detail in the following section.
The release of Macromedia Flash MX and Flash Player 6 marked the first accessible versions of the Flash platform. As of today, Freedom Scientific's JAWS (version 4.5 and better), GW Micro's Window Eyes (version 4.2 and better), and Dolphin's HAL are screen readers that support Flash. While Flash has long been an essential enhancement to the content for people with cognitive disabilities, it was only with this release that people with visual impairments were able to access Flash content.
Flash uses Microsoft Active Accessibility (MSAA) to deliver information about Flash movies to screen readers and other assistive technologies. MSAA operates as the go between for the Flash player and the screen reader. The Macromedia Flash Player creates a list of objects on the screen and records them on the MSAA "data tree". The screen reader will read this list as it encounters Flash content. As changes are made to the screen, the MSAA data tree is updated. As the movie changes, the screen reader returns to the top of the movie and starts reading through the list again.
By default, text objects in a Flash movie are read by screen readers. Screen readers are also able to identify buttons and movie clips with attached scripts. Screen readers however, cannot look at a graphic element on the screen and communicate its meaning. It is up to the designer to assign a text description of any graphic or animated elements in a Flash movie. This information can be assigned via either the accessibility panel or ActionScript. Some properties, such as "Make Child Objects Accessible" or ".forcesimple" have no counterpart in html. Designers will need to rely on information in this document as well as information found on the Macromedia Accessibility Resource Center to learn more about these properties and the associated techniques.
Screen readers and MSAA shape the experience of Flash content for users with visual disabilities in ways that are often quite unfamiliar to sighted designers. Given that screen readers always start from the top of the movie and can only read one thing at a time, there are some forms of Flash content that simply can not be made accessible. For example, many simulations require users to attend to several variables at the same time. Decisions must be made based on multiple factors and relayed back to the simulation quickly. While this is easy for people who are blind to do in the real world, it is quite difficult when using a screen reader.
Defining User Requirements
Accessibility is often defined in terms of two distinct measures; compliance with standards and usability for people with disabilities. The first measure is more easily quantified. You read the standard, test the content and decide if it passes. If all tests are met successfully, then the content is considered accessible. Yet the reality of accessibility is often more complex. The most common accessibility guidelines, the Section 508 Standards and the W3C Web Content Accessibility Guidelines, are written to support the accessibility of HTML content. While there are areas of overlap, the issues of HTML and Flash accessibility are not one and the same. The techniques associated with some requirements are quite different in Flash. At the same time, there are issues associated with applications created with Macromedia Flash that do not exist in HTML at all.
For this reason, it is extremely important that content created with Macromedia Flash be evaluated in a way that includes more than conformance with a set of standards. In order for Flash applications to be considered accessible, they should be evaluated against a series of use cases that includes people with disabilities. Just as designers frequently preview content in a variety of browsers and across operating systems, it is important that developers get into the habit of previewing content under the conditions of these use cases. Many developers find this to be the greatest challenge of accessible design with Flex. In particular, the screen reader poses a challenge for developers who tend to be a visually oriented group of individuals.
This section is intended to help developers understand a very basic set of use cases. The list below provides developers with a set of criteria to help them understand strategies and tools used by people with disabilities. While this list is not comprehensive, it serves as a useful thumbnail guide.
A user who is blind:
|
A user who is visually impaired (e.g. person with 20/300 vision):
|
A user who is visually impaired due to being color blind:
|
A user with a mobility impairment:
|
A user who is deaf or hard of hearing:
|
[next] |
Created: March 27, 2003
Revised: July 29, 2006
URL: https://webreference.com/authoring/flash/1
Find a programming school near you