Best Practices for Accessible Flash Design. by Bob Regan

Transcription

1 by Bob Regan August 2005

2 Copyright 2004 Macromedia, Inc. All rights reserved. The information contained in this document represents the current view of Macromedia on the issue discussed as of the date of publication. Because Macromedia must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Macromedia, and Macromedia cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for information purposes only. MACROMEDIA MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Macromedia may have patents, patent applications, trademark, copyright or other intellectual property rights covering the subject matter of this document. Except as expressly provided in any written license agreement from Macromedia, the furnishing of this document does not give you any license to these patents, trademarks, copyrights or other intellectual property. Flash8, Flash Basic 8, Flash Professional 8 and Flash Player 8 are either trademarks or registered trademarks of Macromedia, Inc. in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. Macromedia, Inc. 600 Townsend Street San Francisco, CA

3 Contents Introduction...1 Define User Requirements...2 Technical Requirements...4 Key Concepts...5 Labels...7 Role...8 State...8 Structure...8 Accessibility Best Practices...9 Provide Text Equivalents...9 Provide Context Control Reading Order Control Animation Ensure Keyboard Access...20 Progressive Disclosure Enable Component Accessibility Provide Captions...24 Provide Control over Audio Playback...25 Use Color Wisely...25 Support Users with Low Vision Conclusion...27 Resources August 2005 Page iii

4 Introduction This document has been written for web designers who wish to make accessible, interactive rich media. This guide to creating accessible Macromedia Flash content assumes no previous knowledge of accessibility or assistive technology. Included within are the following key topics for developing accessible Flash content: Define User Requirements Technical Requirements Key Concepts Flash Accessibility Best Practices The first section, Define User Requirements, presents a number of use case scenarios in which fictional characters provide a framework for understanding users with disabilities. These personas illustrate the broad range of disabilities that a designer needs to be aware of and highlights the unique issues, challenges, techniques and tools of each. The second part, Technical Requirements, establishes the base set of requirements for developing accessible Flash. As well, hints, tips and special considerations of a technical nature are shared here. The third topic, Key Concepts, introduces ideas common to computer programming that remain relevant to developing accessible Flash content. These concepts include label, role, state and structure and provide a means to explore how a user manipulates objects within a Flash movie. Finally, Flash Accessibility Best Practices offers a number of recommendations for creating accessible design in Flash. These are: Provide Text Equivalents Provide Context Control Reading Order Control Animation Ensure Keyboard Access Progressive Disclosure Enable Component Accessibility Provide Captions Provide Control over Audio Playback Use Color Wisely Support Users with Low Vision August 2005 Page 1

5 Define User Requirements For many Flash designers, the single greatest challenge to understanding accessibility is how to best appreciate the experience of people with disabilities. A web designer s inherent talent is an ability to perceive the world in a unique visual way. The skill of the web designer allows her to view, conceptualize and translate visual information into layout and graphics. This is a fundamental and powerful way of seeing and understanding the world that should not be taken for granted. To understand accessibility and implement it in practice is to ask designers to set their visual skills aside. The first thing to do when addressing accessibility is to step outside of our frame of reference and consider the perspective of users with disabilities. Key questions, such as the following, arise: What are the specific issues that prevent users from accessing content? What are the tools used by people with disabilities to navigate the Internet? What techniques and interfaces are used to make working with the web easier? The following list of fictional characters illustrates common issues for people with disabilities and may be helpful when planning out your design project. The list is certainly not exhaustive but should serve as a model for the wide range of disabilities that must be considered. What is important here is that a consistent set of use case scenarios becomes an integral part of the plan, build and test phases of your accessible Flash web design project. John, 53, a user who is blind: Uses the Window Eyes 5.0 screen reader Uses the keyboard exclusively for input and navigation Does not use the mouse Relies on audio cues to let him know if something has happened on screen John is a university professor who uses the computer for all of the same tasks as his colleagues, who are not visually impaired. He writes and research papers, and reviews student work. John is part of a dance troupe in town and uses the web extensively to read up on a wide range of topics. He is easy going, most of the time, but what really he really finds frustrating is when web sites of interest do not make their content accessible. Ava, 30, a user who is visually impaired (e.g. person with 20/300 vision): Relies heavily on the keyboard for input Uses a mouse, but only when she can t use the keyboard Uses ZoomText, a screen magnifier to receive information about the movie Will also use JAWS with ZoomText when there is a lot of text August 2005 Page 2

6 Ava is a developer for a small consulting firm. She can see, but only with significant magnification or when objects are held very close. She uses the computer every day for work to review and write code for her clients. She uses ZoomText most of the time but will occasionally use a screen reader to read long text passages. Ava loves music and is a fan of Stevie Wonder. Ironically, Stevie Wonder s site, a Flash site, is completely inaccessible. She has been waiting for the new album and checks the site from time to time for information but finds it a struggle to get around. Jeff, 22, a user who is color blind: Needs visuals that are usable given specific color limitations Like 10% of all men, Jeff is color blind and cannot distinguish between certain colors. Generally speaking, he does not have much trouble using the web. However, trouble arises on sites where red buttons are placed on a green background, or where red and green buttons are next to one another to start and stop movie actions. This lack of contrast in foreground and background colors and red and green combinations can be frustrating for users who are colorblind. Makoto, 48, a user with a mobility impairment: Uses only the keyboard to navigate the site Makoto was involved in an auto accident and lost the use of his hands. He relies on a mouth stick (a long stick in his mouth with a small rubber pointer tip on the end) to navigate web pages and applications via the keyboard. He uses the tab and Enter keys to move between objects on the screen, as well as the Windows sticky keys tool to create key combinations. Makoto works at a local rehab center with other adults with disabilities. Computers are used to complete paperwork for clients and file weekly reports. A devoted New York Yankees fan, Makoto takes a few minutes each day to check the online Baseball scores. His favorite baseball page is The Sporting News. However, accessing this page can be a tedious experience due to the many navigation links he has to tab through to get to the day s top stories. Karen, 29, a user who is deaf: Receives information from the movie in a visual form. Deaf since birth, Karen is an art teacher at the local high school. With two young kids at home and needing to maintain her teaching license, Karen decided to take the required courses online. Accessing the course was no trouble for Karen; however, a problem arose concerning some instructional video content. While most of the videos used in the coursework contained closed captioning, a few did not. In the cases where no captioning was available, Karen had to request a full transcript from student services, which often took more than a week to be delivered. As a result, Karen fell behind in her course work. August 2005 Page 3

7 Technical Requirements Web accessibility can be broadly described as the capacity of any user, regardless of disability, to access the same content and information. With regard to accessible Flash web content, obstacles for users with disabilities have two sources: issues of design; or issues of assistive technologies. In a following section, the techniques for successful, accessible Flash design will be discussed. In this section, we ll investigate the technical requirements and review assistive technologies. Developers creating accessible Flash must meet the following minimum requirements: Macromedia Flash Player 6 or later Windows 98, 2000 or XP Microsoft Internet Explorer 5 or later Screen readers: o o GW Micro Window Eyes 4.2 or later Freedom Scientific JAWS 4.5, 6.1 or later o IBM Home Page Reader 3.04 o Dolphin HAL 6.50 o KDS PC Talker (Japan) The release of Macromedia Flash MX and Flash Player 6 marked the first accessible versions of the Flash platform. This version of the player serves as a minimum requirement for accessible Flash content. All accessible Flash content must be tested on the Microsoft Windows platform. While there have been recent improvements to the Apple Macintosh OS 10.4 release (Tiger), including a built in screen reader called VoiceOver, the Flash Player does not support this screen reader. All accessible Flash content must be tested using Microsoft Internet Explorer. At the time of publishing this document, Internet Explorer was still the only accessible browser available. The Mozilla Project has made some improvements with the Firefox Browser, and support for screen readers will soon be available. However, the version of the Flash Player that runs in Firefox is not yet accessible. Designers often question the wisdom of testing accessible content using only one browser and one platform. While the future of cross platform and cross browser accessibility looks promising (with the recent improvements at Apple and Mozilla), the reality is that today, people with disabilities are almost exclusively restricted to using Windows with Internet Explorer. For now, designers should feel comfortable testing their content using only this configuration. August 2005 Page 4

8 As part of your development, production and testing phases for accessible Flash content, designers should rely on a minimum of one screen reader. While Flash content does not behave exactly the same in all screen readers, it is generally true that an application that functions properly in one screen reader will likely work in another. Applications with greater complexity or a wide range of users should plan to test using more than one screen reader. Here s how rich media content is passed from the web page to the screen reader. 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 then read this list as it encounters Flash content. As changes are made to the screen, the MSAA data tree is updated. Changes to the movie prompt the screen reader to return to the top of the movie and commence 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 determine 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 complex forms of Flash content that simply can not be made accessible. For example, many simulations require users to attend to several objects at the same time. Decisions must be made based on multiple factors and relayed back to the simulation quickly. This type of multitasking activity may be easy to do in the real world for someone who is blind, but can pose a real challenge while using a screen reader. Key Concepts In its flexibility, Flash allows designers to create simple objects that can be used as a number of different controls. Take this simple circle for example. August 2005 Page 5

9 If we add a label and a script to this circle, it becomes a button. Another slight change and it becomes a slider. Yet another alteration and this same circle is now a dial. Visually, it may be obvious what these controls are and how to operate them. However, to a screen reader user it may not be obvious. For simple buttons, no extra effort is required. Yet as controls become increasingly sophisticated, additional information about the control is required. This is where Flash accessibility begins to approach the accessibility of desktop applications. In HTML, there are only 12 different types of controls. The screen reader knows how to handle them, and an experienced screen reader user understands how the controls work. In Windows, there are 76 different types of controls and an infinite variety of custom objects. While many of these controls are also familiar to screen reader users, there are an equal number of users who may not understand how a complex control works. Further, the combinations of controls can add greater levels of difficulty to an application. August 2005 Page 6

10 We must return to the point of expecting designers to have the perspective of a disabled user. It is important to create accessible controls that work both in a technical sense (are accessible to a screen reader) and in a practical sense (controls that are familiar and work as expected). In other words, the user has an opportunity to understand how a control functions without significant effort or help from someone else. Macromedia Flash allows authors to create these types of controls in ways that other applications simply can t. While technologies such as SVG and Ajax have generated interest in the last couple of years, there is no way to expose these types of controls to a screen reader using these technologies. When accessibility is a priority, these technologies should be avoided. The following set of key concepts provides designers with the fundamentals to understanding what makes an accessible control in a Flash movie. Labels The label for a control answers the question, What is this thing? Every control in a movie should have a label that describes the function of the control. Labels should be concise and read immediately before, or together with the control. In this simple example, the label for the button is clearly displayed as text inside of the button. It is important that the screen reader also reads the label. When the label for a control is an icon, a text equivalent for the label should be provided as a text equivalent for the button. For example, the button below shows a commonly used icon for play. It is up to the designer to make sure this button has a label associated as a text equivalent. If the function of the control changes, so should the label. The example below shows a pause button from a movie controller. Typically play and pause are included in the same button. If the user presses play, the button transforms to a pause button. As the user activates this button, the label should update as well. August 2005 Page 7

11 Role The role of a control answers the question, What does this thing do? As shown previously, a simple control made of a circle can be a button, a slider or a dial, or any number of possibilities. Flash automatically assumes that if a script is attached to an object, then that control is a button. The designer can formally specify a role in MSAA using the Flash component architecture. However, this is a significant amount of effort and well beyond the scope of all but the most complex development projects. Instead, the role can be exposed using simple text objects that provide hints to the user. The role helps the user to understand how a control operates. If a control is defined as a combo box, then the user will naturally assume it will behave similarly to other combo boxes they have come across in the past. The role provides a quick and easy method of explaining to a user how a control is operated. State The state of a control answers the question, Is this thing on or off? or At level 1, 2 or 3? and so on. Many controls have multiple settings. Think of a dial that sets a skill level in a game using the control shown below. In this case, there are three possible settings: level 1, level 2 and level 3. The position of the red arrow lets us know visually that level 2 is selected. However, screen readers have no way of knowing anything about the red arrow or how many possible levels there are. In controls with multiple settings, designers need to let the user know how many possible states there are for a control and what state is selected. In the example above, we might use a text object or even the name property to read, Level 2 of 3 is selected. Structure The structure of a control answers the question, How does this thing relate to the other things on screen? It is important that individual elements within a control not be read separate from the rest of the control. In Flash, this is generally a matter of controlling the reading order. In the example above, it is crucial that the designer ensure that the text, level 3 is read right after the text level 2. In some cases, Flash reading order can get jumbled based on the position on screen. Mixing up elements of content and controls can result in a terribly confusing experience for the end user. August 2005 Page 8

12 Accessibility Best Practices When developing accessible Flash content, there are a few basic rules that must be observed. The following comprises a list of best practices for accessible rich media design. This list is not intended to be fixed, nor is it comprehensive. It is up to designers to make decisions about individual applications and whether they meet the requirements as outlined in the use case scenarios. 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 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, be aware that both JAWS and Window Eyes read this content automatically rather than upon user request. As a result, long descriptions used in this field can result in a tedious listening experience. 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, Moon orbiting a planet. August 2005 Page 9

13 To provide a text equivalent using ActionScript, a new object must be created for each instance and then the accessibility information is 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. _root._accprops = new Object(); _root._accprops.name = "Moon orbiting planet"; _root._accprops.forcesimple = true; Accessibility.updateProperties(); The following is a list of accessibility properties in ActionScript. Table 1: Accessibility Properties in ActionScript Property Type Equivalent in accessibility panel Applies to.silent boolean Make Movie Accessible/ Make Object Accessible (inverse logic).forcesimple boolean Make Child Objects Accessible (inverse logic) whole movies buttons movie clips dynamic text input text whole movies movie clips.name String Name whole movies buttons movie clips input text.description String Description whole movies buttons movie clips dynamic text input text 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, Make object accessible. August 2005 Page 10

14 This same property can be set using ActionScript. The following code example shows an object set to be inaccessible using the.silent property. logo_mc._accprops = new Object(); logo_mc._accprops.silent = true; Accessibility.updateProperties(); Case 2: Labels for buttons and controls Flash includes an option called auto labeling. If a text object is used within a button, the Flash player will assume that text object is the label for the button. The same holds true for movie clips used as buttons. 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 override the auto labeling without disabling the auto labeling completely. Auto labeling can only be turned off on the accessibility panel and it cannot be changed dynamically once set. The screen shot below shows the auto labeling option enabled. August 2005 Page 11

15 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. Provide Context Screen readers are not able to provide clues to a screen reader user about the layout or structure of a Flash movie, or individual controls within that movie. As a result, it is important that complex movies provide descriptions about the movie itself, as well as its important parts and controls. Determining when a movie is sufficiently complex to merit a description or when a control requires additional cues is really up to each designer. Describe the movie Designers should provide a description of the movie at the root level to let the user know what the movie or application is about. This description should be written to help the user get oriented to the application quickly and understand the key controls and shortcuts used. This can be accomplished in a number of ways. First, this information may be placed on a separate screen in the Flash movie or a separate HTML page. It is recommended that in this case, a link to the information screen be placed at the top of the page in a button titled site info. Using this short title will help prevent the application from becoming overly verbose. This button can be hidden if desired, but to enable sighted users with disabilities to access the same information, it is recommended that a second link to the same information be placed elsewhere on the screen (most likely at the bottom). Expose state Flash allows designers to create an infinite variety of controls. In cases where the user is provided visual cues about the state of a control or a screen within the movie, this information should also be made available via a dynamic text field that is updated as the control is activated. Take the example below. In this case, the movie uses tabs that drop down to indicate which screen is the active screen. While this is a helpful visual cue, this information is not available to screen reader users. August 2005 Page 12

16 To provide a cue for the screen reader user, a text field is hidden under the banner (see circled area below, where the hidden text is made available). Since it is intended to provide information for screen reader users, it need not be visible. As the user moves between screens, the contents of this field can be made to reflect the active screen. In this sample screen shot, a screen reader accessing this as a web page would read: Accessible Flash Site info button Keyboard area August 2005 Page 13

17 Captions button Equivalents button With each area of the site, the text keyboard area will update to reflect the active area. Control Reading Order 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 two 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 the accessibility panel or ActionScript. August 2005 Page 14

18 With the release of Macromedia Flash Player 8, handling issues with the reading order have been significantly simplified. In previous releases, a designer had to specify values for all objects in a movie. Missing one would cause the reading order to revert to the default. This made setting the reading order a tedious and time intensive task. In Flash Player 8, the reading order can be partially specified. The author need list only the objects that they want to control. The remaining objects will follow the default reading order after the specified values. It is still important to consider the reading order of a movie from the beginning of the development process. It is certainly more work to retrofit for proper reading order of a Flash movie after the movie has been completely built. Therefore using a screen reader to evaluate during an ongoing development process can definitely make finding and fixing problems much easier. The key to creating an appropriate reading order is to ensure that the order reflects the structure of the screen. At a high level, the elements of the screen should be reading in a reasonable and consistent order from one screen to the next. For example, one would most often expect that the title of the site would be followed by the navigation, followed by the content. Placing the title of the application at the end of the reading order might create confusion. Finally, the reading order should ensure that elements from each of these higher level groups are not mixed together. For example, the title of the application should not be read between buttons on the navigation bar or pieces of the content on screen. To extend this concept, buttons at one level of a navigation bar should not be read mixed in with buttons on the next level. 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 the accessibility panel or ActionScript The most precise means for controlling reading order is to use tab index values. Tab index values are easily assigned using the accessibility panel or ActionScript. The designer simply assigns each object a value that reflects the desired reading order. August 2005 Page 15

19 Objects within a Flash movie that are assigned a tab index value are then placed at end of the reading order, following the default order. Tab index values need not be sequential. In fact, it is recommended that the order NOT be sequential, to allow designers to add objects into the movie at a later time. Intervals of 10 should be sufficient. Assigning a reading order using ActionScript In cases where the reading order is dynamic or objects are created on the fly, designers will need to use ActionScript to assign tab index values. This is an existing property of all objects in ActionScript. There is no need to create an accessibility object to assign a tab index value. Consider the following simple example. Three circles displayed with the text, Third, Second and First displayed on screen. Using tab index values assigned in ActionScript, we will reverse that reading order. When the following ActionScript is added to movie, the reading order reverses to read First, Second, Third. first_mc.first_txt.tabindex = 10; second_mc.second_txt.tabindex = 20; third_mc.third.txt.tabindex = 30; In general, it is best practice to place the ActionScript controlling the reading order at the root level of the movie in the first frame. August 2005 Page 16

20 Scoping When controlling the reading order using ActionScript, the.tabindex property value has to be assigned to the text object itself, not to the parent. Consider again the example shown above. In this case, the.tabindex property is assigned to the text objects in the circle movie clips. The values of the parent are not inherited by the child. Thus, assigning the.tabindex property values to the circles would not result in the reading order reversing. Static text cannot be controlled It is not possible to provide an instance name to static text objects. As a result, it is not possible to assign a.tabindex property to a static text object and the reading order of static text objects cannot be controlled. In cases that do require precise control over the reading order, designers are encouraged to use dynamic text objects. 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: Removing objects from the reading order There are numerous examples where a designer will want to hide elements from the user and remove them from the reading order temporarily. This is a relatively simple task. However, it should be noted that objects placed behind another object or tucked just off stage are not necessarily removed from the reading order. Screen readers have no concept of whether one object is in front of another or whether it is just barely on stage or completely off stage. Designers need to more formally hide objects if they wish to remove them from the reading order. The easiest means of removing an object from the reading order is to move them completely off stage. The bounding rectangle of the object needs to be more than 1 pixel off stage. Even if the visible object itself is off stage, the bounding rectangle is what matters here. Consider the follow example. Circle One is offstage. However, we can see that the blue bounding rectangle is still on stage. As a result, this object will be read by the screen reader. Circle Two is shown with the bounding rectangle completely off stage. In this case this object will not be read by the screen reader. August 2005 Page 17