Best Practices for Accessible Flash Design

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:

Understanding Accessibility in Flash Defining User Requirements Flash Accessibility Best Practices

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:

Provide Text Equivalents Control Reading Order Ensure Keyboard Access Control Animation Provide Context Enable Component Accessibility Provide Captions Provide Control Over Audio Playback Use Color Wisely Support Users with Low Vision

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:

visual impairments, hearing impairments, mobility impairments, and cognitive impairments.

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 �ata 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 �ake Child Objects Accessible?or ?code>.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:

Uses the keyboard for input exclusively Does not use the mouse Receives information about the movie from a screen reader Receives information about the movie from other audio events Doesn't use a screen magnifier May use a refreshable Braille display rather than hearing the information the screen reader gathers.

A user who is visually impaired (e.g. person with 20/300 vision):

Relies heavily on the keyboard for input May use a mouse, depending on the extent of the visual impairment May use a screen magnifier exclusively to receive information about the movie May use a screen reader exclusively to receive information about the movie May use both a screen reader and magnifier together to receive information about the movie If using a screen reader, may use a refreshable Braille display rather than hearing the information the screen reader gathers.

A user who is visually impaired due to being color blind:

Uses the mouse and/or the keyboard for input Does not need a screen reader or screen magnifier Needs visuals that are usable given specific color limitations.

A user with a mobility impairment:

May be unable to use the mouse May depend more heavily on the keyboard May depend entirely on the keyboard Can receive information about the movie visually.

A user who is deaf or hard of hearing:

Uses the keyboard and the mouse Receives information from the movie in a visual form. Accessibility Best Practices The following comprises a list of best practices for accessible design. This list is not intended to be fixed nor comprehensive. It is up to designers to make decisions about individual applications and whether they meet the requirements outlined in the use cases. Provide Text Equivalents Screen readers are not able to discern the meaning of graphic or animated elements on the stage. As a result, designers must provide a brief text description of graphic elements. Text equivalents can be provided for an either an entire movie, a single object within a movie or a group of objects within a movie. Providing text equivalents for an entire movie Text equivalents should be provided for an entire movie in cases where the movie can be conveyed using a single text equivalent. Examples of this include movies that show a simple animation, banner ads or complex movies that cannot otherwise be made accessible. The text equivalent should be placed in the name field. It is generally advisable to make the contents of the name field short and focused in order to describe the function of the movie. The description field can be used for longer descriptions. However, both JAWS and Window Eyes read this content by default. As a result, long descriptions used in this field can result in an application or page that is tedious to listen to. In cases where a single text equivalent is used for an entire movie, the child objects of the movie should be made inaccessible. This will prevent animations within the move from causing frequent updates to the screen reader. It will also facilitate automated testing of the content for accessibility. The text equivalent may be assigned using the accessibility panel. In this screen shot below, a text equivalent is placed in the name field, �nimation of moon orbiting a planet.?     To provide a text equivalent using ActionScript, a new object must be created for each instance and then the accessibility information assigned. once the name value has been assigned, the accessibility objects must be updated. This is done once for all objects when a change is made. It is not necessary to update each instance of the object. Notice the sample code below includes a line to create the new object for the entire movie. Next, the value is assigned for the .name property and then the child objects are made inaccessible using the .forcesimple property. A complete list of the ActionScript properties is shown below with the corresponding fields on the accessibility panel. 1   2 _root._accProps = new Object();<br>   3 _root._accProps.name = "Moon orbiting planet";<br>   4 _root._accProps.forcesimple = true;<br>   5 Accessibility.updateProperties();   6   view plain | print | copy to clipboard | ? <TEXTAREA class=javascript style="DISPLAY: none" name=code rows=10 cols=60>_root._accProps = new Object();<br> _root._accProps.name = "Moon orbiting planet";<br> _root._accProps.forcesimple = true;<br> Accessibility.updateProperties(); </TEXTAREA> The following is a list of accessibility properties in ActionScript. Providing text equivalents for single movie clip Unlike HTML, not every movie clip or button in a Flash movie requires a text equivalent. There are at least three cases that need to be considered here. Case 1: Setting a movie clip to be silent First, there are elements that are purely decorative, are repetitive or convey no content. These movie clips should be made inaccessible. This can be done using the Accessibility panel by deselecting the option, �ake Accessible.?/p> This same property can be set using ActionScript. The following code example shows an object set to be inaccessible using the .silent property. 1 _root.logo_mc._accProps = new Object();<br>   2   3 _root.logo_mc._accProps.silent = true;<br>   4   5 Accessibility.updateProperties();   6   view plain | print | copy to clipboard | ? <TEXTAREA class=javascript style="DISPLAY: none" name=code rows=10 cols=60>_root.logo_mc._accProps = new Object();<br> _root.logo_mc._accProps.silent = true;<br> Accessibility.updateProperties(); </TEXTAREA> Case 2: Labels for buttons and controls Flash includes an option called �uto-labeling.?If a text object is used within a button or a movie clip used as a button, the Flash player will assume that text object is the text equivalent for that button. It is important in these cases that the child objects of the movie clip are accessible. It is important to keep in mind that only a single text object can be used as a label and the text object must fit completely within the hit area of the button. Auto-labeling also works for components such as radio buttons and list boxes used in a movie. The Flash player will assume text objects above or to the left of the control should be used as the label. Again, only a single text object will be used as a label. If a text equivalent is assigned via the name property using either the Accessibility panel or ActionScript, that value will over ride the auto-labeling without disabling the auto-labeling completely. Auto-labeling can only be turn off on the accessibility panel and it can not be changed once it is set. The screen shot below shows the auto-labeling option enabled.     Case 3: Text equivalents for a single movie clip or button If a text equivalent is assigned for a single object in a movie, this can be done via the Accessibility panel. The text equivalent should be relatively short and should address the function of the object, rather than a longer or more detailed description. This will help prevent the movie from becoming verbose and tedious to navigate. The description field can be used for longer descriptions. However, JAWS and Window Eyes will both read this field by default. As a result, there is no advantage to using this field at this time. Control Reading Order Controlling the reading order of a Flash movie is perhaps the single most important and challenging aspect of accessible Flash design. The default reading order of a Flash movie does not follow a predictable left to right, top to bottom order. As a result, contents of a Flash movie can be difficult to understand. Take the example below. Based on the visual presentation of the alphabet in three rows, it would be natural to expect the reading order to follow alphabetical order. However, the actual reader order jumps between letters in each row. The resulting order is shown below. There are three strategies for controlling reading order. The simplest is to keep the physical size of the movie small. The second strategy requires controlling the reading order using ActionScript. A third strategy places a duplicate version of content off-stage in a single column. It is very important that the reading order of a movie be tested from the beginning of the development process using a screen reader. It is significantly more work to modify the reading order of a Flash movie once the movie has been completed. Therefore using a screen reader to evaluate the reading order as the movie is developed can facilitate understanding when a problem has been introduced and how to rectify the issue. Limit the size of the stage A small Flash movie that is less than 300 pixels wide and consists of a single column or a single row of objects does not require any specific control over the reading order. Examples might include small animations or applications that pop up in a separate window, a navigation bar that consists of a single row or an application that consists of a single column. Controlling reading order using ActionScript The most precise means for controlling reading order is to use ActionScript. This method allows the designer to precisely control the reading order using the .tabindex property in ActionScript. There is no distinction in ActionScript between reading order and tab order. However, when using ActionScript to control the reading order of a Flash movie, all instances within the movie must be included in that list of .tabindex values, including all text fields and decorative elements. Every instance over the life of the movie requires an instance name In controlling the reading order, it is important to ensure that every instance on the stage has an instance name. This includes all text, movie clip and button symbols as well as all components over the life of the movie. Do not use static text Since it is not possible to provide an instance name to static text objects, a single instance of static text will result in the entire reading order reverting to the default. Controlling the reading order using ActionScript requires the use of dynamic text fields. This will have implications for the font used in the application and potentially impact the overall file size. To learn more about handling font symbols in Flash, please visit: www.macromedia.com/support/flash/ts/documents/flashfonts.htm Include off-stage or obscured elements The list of .tabindex values must include all instances over the life of the movie, this includes elements that are not visible and sit off stage or hidden under another instance. It is important that if these elements should be obscured from a screen reader user, the ._visible property should be set to false or the .silent property should be set to true. This also means that elements that are not visible at the start of the movie, but will be visible later must also be included in the list of .tabindex values. Controlling reading order when loading swfs at runtime In cases where a series of child .swf files are loaded into a parent movie, the list of .tabindex values must be listed in the child movie clip. However, it is important that the values list in the reading order of each child swf be unique. For example, if two child movies loaded into a parent movie each have three elements with .tabindex values of 1, 2 and 3, the screen reader will read the first value of the first movie loaded, then the first value of the second movie loaded. Next, the screen reader will read the second value of the first movie clip loaded and then the second value of the second movie clip loaded and so on. In order to read the contents of the first movie followed by the contents of the second movie, the list of .tabindex values for the first movie should be 1, 2, 3 while the list of values for the second move should be 4, 5, 6. These values need not be sequential, but they should be unique. Using 3rd party repair and validation tools As of this writing, there is one third party tool from HiSoftware available to help build a reading order with Flash content. Called, ACCRepair, this tool is sold as an extension to Flash. It will look for missing instance names, convert static text into dynamic text and build the reading order. This tool can be particularly helpful in cases where there are a large number of instances on stage. For more information about ACCRepair, see: www.macromedia.com/software/flash/extensions/accrepair/ About the Author Bob Regan is a solutions architect for vertical markets at Adobe Systems, Inc., serving as the technical lead for the Education, Government, Financial Services, Manufacturing, Telecommunications and Life Science markets. Bob is also an accessibility advocate with Adobe where he looks at accessibility issues from product design, engineering and content authoring through to the end user.   source : http://www.webreference.com/authoring/flash/index.html