Accessibility Best Practices for Flex

Macromedia Flex provides developers with the ability to create a new generation of accessible Rich Internet Applications.

Macromedia Flex includes 22 components with built-in accessibility support. These components automate many of the most common accessibility practices and radically simplify and accelerate the process of creating accessible Rich Internet Applications. Designed and tested by Macromedia, these components automatically inherit accessibility features and help the developer apply accessibility standards to their application development with significantly less work.

This article is designed to establish a basic framework that you can use to develop accessible applications with Macromedia Flex. The central tenet of accessible design is to test, test, and test again. This also presents the greatest challenge of accessible design. To build accessible applications with Flex, developers must cultivate a limited understanding of a screen reader and other assistive technologies.

This article will cover the following topics:

• Defining User Requirements
• Flex Accessibility Best Practices
• Accessible Components Information

The first section, Defining User Requirements, presents a limited number of use cases. You can test and implement your application with these use cases. Each use case has its list of issues and challenges; I also explain which techniques and tools may be used in each use case to view an application on the web. The second section, Accessibility Best Practices, guides you through a series of recommendations for developing accessible applications in Flex. These are:

The third section lists each of the accessible components that ship with Macromedia Flex. For each component, I've noted known issues and end-user instructions.

Defining User Requirements

Accessibility is often defined in terms of two distinct measures:

• compliance with standards
• usability for people with disabilities

The first measure, compliance with standards, is easier to quantify: As a developer, you read the standard, test the content, and decide if it passes. If the application succeeds all tests, the content is accessible. Yet, the reality of ensuring 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 some areas overlap, the issues of HTML and Flex accessibility are not the same. The techniques associated with some requirements are quite different in Flex. Likewise, there are issues associated with creating accessible Macromedia Flex applications that do not exist in HTML at all.

For this reason, it is very important that when you create a Macromedia Flex application that you evaluate its accessibility on more than its conformity with a set of standards. To consider Flex applications accessible, evaluate them 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 used to previewing content under accessibility use cases. Many developers find this to be the greatest challenge of accessible design with Flex. In particular, the screen reader can pose a challenge to visually-oriented developers.

The following section explains a very basic set of use cases. You can use the list below as criteria to help you understand strategies and tools used by people with disabilities. While this list is not comprehensive, it is a useful start.

A blind user:

• Uses the keyboard for input exclusively
• Does not use the mouse
• Receives information about the application from a screen reader
• Receives information about the application 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 visually-impaired user (e.g. a 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 application
• May use a screen reader exclusively to receive information about the application
• May use both a screen reader and magnifier together to receive information about the application
• If using a screen reader, may use a refreshable Braille display rather than hearing the information the screen reader gathers

A visually-impaired user that is 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 based on specific color limitations

A mobility-impaired user:

• 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 application visually

A user who is deaf or has a hearing impairment:

• Uses the keyboard and the mouse
• Receives information from the application visually

It is important that you evaluate your Flex content using a screen reader throughout the development process. Flex components have been tested and optimized for use with JAWS 4.5 from Freedom Scientific. An additional script for JAWS is available to enhance support for the Tree Control and Radio Buttons; read more about it at: www.macromedia.com/macromedia/accessibility/features/flex/jaws.html.

Spend some time learning to use the screen reader and getting comfortable with the controls. Test for accessibility throughout the development process. Don't leave accessibility to the end of the development process. When left to the end of the development cycle, developers tend to cut accessibility testing from the application entirely, as they identify issues that they should have addressed early on.

Accessibility Best Practices

The following comprises a list of best practices for developing accessible applications with Macromedia Flex. This list is not intended to be final nor comprehensive. It is up to developers to decide whether individual applications meet the requirements outlined in the use cases.

Enabling Application Accessibility

To create an accessible application with Macromedia Flex, you must enable accessibility for that application. Flex applications are not accessible by default. When you enable accessibility, Flex imports the accessibility object for each component used in the application. This results in a small but non-trivial increase in the size of resultant SWF file.

There are three strategies for enabling the accessibility of a Flex application.

• Enable accessibility by default for all Flex applications.

  To enable the accessibility for all Flex applications, edit the flex-config.xml file and set the <accessible> property to true, as the following example shows.

  <mxml-compiler>
  		…
  		<accessible>true</accessible>
  		…
  </mxml-compiler>
  

  This technique has an important tradeoff in terms of performance. Once you have enabled accessibility for a Flex Application, the overall file size of the resulting SWF file can increase approximately 1K for each component. Since there is no easy way to remove these objects once you have included them in an application, accessibility disabled by default in Flex.

• Enable accessibility for an individual application.

  If you have not enabled accessibility for all applications by default, you can enable it for an individual application by appending the query parameter, accessible to true, as the following example shows:

  http://www.mycompany.com/myflexapp/appl.mxml?accessible=true

  In general, this will be the most common strategy for enabling the accessibility of a Flex application. It provides a means to ensure optimal performance for users that do not require accessibility support. It is acceptable to provide users with multiple links to the same application: one with accessibility enabled, another without.

• Enable accessibility using the command line compiler.

  When you compile a file using the mxmlc command-line compiler, you can use the -accessible option to enable accessibility, as the following example shows.

  mxmlc -accessible c:/dev/myapps/mywar.war/appl.mxml

Controlling Reading Order

The reading order describes the order in which a screen reader reads the content on the screen. The default reading order of a SWF file does not follow a predictable left-to-right, top-to-bottom order. For simple Flex applications, the reading order may not be an issue. However, complex Flex applications may be difficult for blind users to understand.

Take the example below. It consists of a Tree control, a DataGrid control, and a TextArea control. For this application, the screen reader will read the contents of the Tree control, the contents of the DataGrid, and then the contents of the TextArea. In this case, a developer should read the content using a screen reader to ensure that the order is not confusing to the end user. In this case, the screen reader would read the title, followed by the Tree control, the DataGrid control, the Text box, and then the links below. Since this is roughly how any other user would follow the application visually, the developer in this case does not need to pay any additional attention to the reading order.

Figure 1. Screen shot of Flex application with three components.

In this second example, it is a significantly more complex application. In this case, it is possible that labels associated with specific controls are be read at the same time as the control itself. Thus a user may believe he should enter the ZIP code in a field when in fact, he should enter a telephone number. In complex applications like this, the developer should take some steps to control the reading order.

The easiest method for controlling the reading order is to keep the user interface relatively simple. Efficient use of the Accordion navigator container or the TabNavigator container can help guide users through an application easily. At the same time, these components help to control the reading order of an application to ensure screen reader users can use the application easily.

Applications with more complex layouts are more likely to create issues for screen reader users. The example below shows a common case of an application that creates issues for screen reader users. The application uses a Repeater object to populate a grid. There are four rows of products, each product have an image and a label. Since the labels and images are in separate components, they might not necessarily be read sequentially in a predictable order. This is because of the relatively simplistic way that the Flash player computes the tab order. As a result, you must control the reading order.

Figure 2. Screen shot of a Flex application containing four rows of images and labels in a VBox container; may require a developer to control reading order.

In this case, you must use a second method for controlling reading order: You must assign values to the tabIndex property within the MXML file. You use this method to precisely control the reading order. In a SWF file, there is no distinction between reading order and tab order; however, when controlling the reading order of a Flex application using the tabIndex property, all objects within the application must include a tabIndex value, including all text fields and decorative elements that are not tab stops within the application.

Note: This method does not work correctly if a tab element extending from view.as is present in the file, such as List or DataGrid. This is an known issue in the current Flex release.

Figure 3. A smaller version of the previous example showing three images and three labels in a VBox container.

In this smaller version of the example above, you specify the tabIndex values using the code below. To be effective, you must specify the tabIndex values for all objects within the application. Missing a single object causes the reading order to revert to the default order.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml">
   <mx:Model id="catalog" source="assets/catalog.xml"/>
   <mx:Panel title="Your Choices">
      <mx:HBox>
         <mx:VBox>
            <mx:Image width="60" height="56" source="assets/icecreampint.jpg" toolTip="Ice Cream Pint" tabIndex="1"/>
            <mx:Label text="$42.00" tabIndex="2"/>
         </mx:VBox>
         <mx:VBox>
            <mx:Image width="60" height="56" source="assets/takeout.jpg" toolTip="Chinese Takeout" tabIndex="3"/>
            <mx:Label text="$53.00" tabIndex="4"/>
         </mx:VBox>
         <mx:VBox>
            <mx:Image width="60" height="56" source="assets/dovecandle.jpg" toolTip="Dove Tea Light" tabIndex="5"/>
            <mx:Label text="$18.00" tabIndex="6"/>
         </mx:VBox>
      </mx:HBox>
   </mx:Panel>
<mx:Link label="Product images courtesy of Lavish" tabIndex="7"/>
</mx:Application>

Providing Instructions

Screen readers are unable to provide many cues to a screen reader user about the layout or structure of a Flex application. As a result, it is important that you provide instructions about the purpose of the application, how to complete essential tasks, and how to get additional help, if available.

Flex applications bring the power of desktop applications to the web. For users with and without disabilities, Flex applications may represent the first time users encounter Rich Internet Applications. For screen reader users, it is particularly important to provide information about the layout of the site, the controls used, and instructions describing how to complete core tasks within the application.

Some of the components provided with Flex server are new controls to users. In addition, some components may create known issues with some assistive technologies or require the use of scripts. You'll find information about each component in the next section.

The simplest way to provide instructions is through the description property for the resulting Flash application. Ideally, a user would read these instructions each time they return to the top of the application; therefore, it's important to make instructions short and concise. Below is a sample of the code used to describe the Blog Reader application that ships with Flex.

First, a function is defined to assign the description value.

function accessibleInit() { 
	var desc = createObject("TextInput","desc",0); 
	desc.x = 0; 
	desc.y = 0; 
	desc.width = 0; 
	desc.height = 0; 
	desc._accProps = new Object(); 
	desc._accProps.description= 'Access instructions. The Flex Blog Reader reads entries from different Blogs on the Web. To interact with this application, turn forms mode on after entering the application.';
}

Next, the function is called from the <mx:Application> element.

<mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml"
    	initialize="accessibleInit();    
	pageTitle="Flex BlogReader">

For more complex instructions, it may be a appropriate to place the instructions in a separate screen. This may simply be a button or a link that opens a window describing the application. It is recommended that this element be the first thing that a screen reader encounters when it reads the application. It is typical to put a hidden link or button at the top of the application. This makes it very easy for screen reader users to get information about the application. Another common method is to put a second redundant link at the bottom of the screen so that sighted users can access the same information.

Ensuring Keyboard Access

It is important that users can use all controls that are available through the mouse through the keyboard too. This type of functionality supports mobility-impaired users as well as screen reader users. The components included with Macromedia Flex and the Macromedia Flash Player facilitate keyboard access by automatically making mouse-defined events accessible through the keyboard. Most Flex applications are accessible through the keyboard by default.

There are two common exceptions to this rule: drag-and-drop actions and cases where users have difficulty using the keyboard to perform tasks. First, an application with drag-and-drop actions excludes users who have difficulty using the mouse. Hence, it is important to provide redundant keyboard events for drag-and-drop actions. For example, if a user can drag a product into the shopping cart, another user should be able to accomplish the same task by pressing the Enter key. One way to do this is to simply use the link rather than the image component in these cases. Since the link component is keyboard accessible and is capable of displaying an image as an icon, it accomplishes the same goals as the image component. In addition, you can easily assign a redundant event to the link that puts the product to the shopping cart.

Second, just because users can access the controls through the keyboard, does not mean it is easy for them to do so. For some individuals, even a single key press requires effort. In thinking about keyboard access, identify the core tasks associated with the application and assign keyboard shortcuts for those applications. For example, to provide quick access to the help screen, you might assign the "?" key as a keyboard shortcut. This way, a user simply presses the "?" key at anytime to view the help screen. To do this, use ActionScript to create a listener object as in the following example.

KeyListener = new Object();
KeyListener.onKeyDown = function()
     {
            if (Key.getAscii() == 63) 
	    {
            // call same code that button's click handler calls
            }
}

Key.addListener(KeyListener);

Providing Captions

You can use Macromedia Flex to deliver high-quality Flash video content. For any audio you provide, also provide synchronized text in the form of captions. The most flexible and straightforward way to deliver caption data in a Flash application is to stream caption data at runtime. This is possible with both Hi Caption SE from Hi Software and MAGpie from the National Center for Accessible Media. Both create a custom XML file with caption data specifically for Flash. This file strips down XML data included in captioning standards, such as SAMI and SAPI for improved performance in the Flash player.

HiCaption SE includes a component that imports an XML file and delivers it through a pre-built closed-captioning interface. The designer can modify the look and feel of the icon as well as the text used to deliver the captions.

For more information on Hi Caption SE, visit:

www.macromedia.com/software/flash/extensions/hicaption/

Providing Text Equivalents

Screen readers cannot discern the meaning of graphic or animated elements on the stage. As a result, designers must provide a brief text description of graphic elements. Designers can provide text equivalents for an entire application or a single object within an application.

Flex applications commonly present images using only the Image component or the Loader component. To convey the contents of these components to a screen reader, Flex delivers the text equivalent through the toolTip property of the Loader component. This property also makes content visible to sighted users as they put their mouse over an image.

Figure 4. Sample application showing a tooltip used together with an image.

The code for this example is as follows:

<mx:Image width="60" height="56" source="assets/icecreampint.jpg" toolTip="Ice Cream Pint"/> 

You can provide more detailed descriptions of images using the description property for the image._accprops object. To provide a detailed description of the image of the Ice Cream Pint, use the following code.

<mx:Image width="60" height="56"
   source="assets/icecreampint.jpg" 
   toolTip="Ice Cream Pint 
   load="event.target._accProps = 
      new Object();
      event.target._accProps.description  = “Our fine Ice Cream Pint provides the perfect serving dish for your homemade ice cream treats”/>

You might use this strategy in cases where more detail is provided within the image itself, or in a separate panel. When the description is in a separate panel, it can be hard for the screen reader user to realize the contents elsewhere on the screen have changed. Not all images require a description field. In fact, this would make most applications too verbose and tedious to use.

Using Color Wisely

When selecting color in Flex content, consider issues for visually-impaired users who have difficulty viewing color due to color blindness and reduced vision. Color should not be the only way of providing information. For example, never use the following type of design or instructions, “Click the red button to move forward and the green button to move back.” It is acceptable to reference color, but include a second indicator at the same time. The same example would be acceptable if you were to add a reference to position as well. For example: “Click the red button on the right to go forward and the green button on the left to go back.”

Select foreground and background colors that sufficiently contrast to ensure readability. For instance, if your application were displayed on a black and white television, would the colors be readable? Colors that lack contrast can make it difficult for users to read elements on a page.

Accessible Components Information

To accelerate developing accessible applications, Macromedia Flex includes 22 components with built-in accessibility support. As mentioned above, these components automate many of the most common accessibility practices, such as providing text equivalents, labeling controls and ensuring keyboard access. Using these components helps you to comply with accessibility standards and to ensure a consistent user experience across your Rich Internet Applications.

To conclude, the beauty of creating accessible applications with Flex is that Flex already addresses the most difficult aspects of keyboard and screen reader access in its components. Ensuring accessibility in rich media has never been easier.

Accessibility is an issue of ensuring each individual's experience, not merely complying with standards. This document, like all guidelines for accessibility is only helpful if it leads developers to improve usability in their applications for people with disabilities. The only way to be certain if your application is usable is to ask. I strongly encourage all developers to include people with disabilities in the development process. You can accomplish this through formal usability testing for your large applications. Alternatively, you can simply invite people to review early builds of the application and comment on it. This can provide important feedback at an early, useful stage.

Macromedia is continually reviewing and updating accessibility information. Visit the Macromedia Accessibility Resource Center for the latest on accessibility and Macromedia Flex.