Adobe® Flex® 4 provides developers with the ability to create a new generation of accessible rich Internet applications (RIAs). With a set of 35 accessible components, Flex radically simplifies the process of creating accessible RIAs for the developer. Each component has been designed and thoroughly tested for accessibility. Applications using these components inherent these accessibility features, leaving the developer with a significantly smaller set of concerns to address.
The central tenet of accessible design is to test repeatedly, which also presents the greatest challenge. To build accessible applications with Flex, developers need to cultivate at least a limited understanding of a screen reader and use cases that include people with disabilities. Following is a basic framework with which to approach developing accessible applications for Flex 4. The first section, "Defining user requirements," presents a few use cases, which may be implemented as personas in the design process with an explanation of issues, challenges, techniques, and tools used in each case. The second section, "Accessibility best practices," walks through a series of recommendations for developing accessible applications in Flex. Finally, the third section, "Accessible components information," lists the accessible components that ship with Flex.

Accessibility is often defined in terms of two distinct measures: compliance with standards and usability for people with disabilities. The first is more easily quantified — you read the standard, test the content, and determine if it passes. If all tests fare successfully, then the content is considered accessible. But the reality of accessibility is often more complex. The most common accessibility guidelines, Section 508 standards and World Wide Web Consortium (W3C) Web Content Accessibility Guidelines, are written to support the accessibility of HTML content. While there are areas of overlap, the issues surrounding HTML and Flex accessibility are not one and the same. The techniques associated with some requirements are different in Flex. At the same time, there are issues associated with applications created with Flex that do not exist in HTML.

For this reason, it is extremely important that rich Internet applications (RIAs) created with Flex be evaluated in a way that includes more than conformance with a set of standards. For Flex applications to be considered accessible, they should be evaluated against a series of use cases that include people with disabilities. Just as designers frequently preview content in a variety of browsers and across operating systems, developers must preview content under the conditions of these use cases. Many find this to be the greatest challenge of accessible design with Flex, particularly in use cases that include screen readers, as developers tend to be visually oriented.

This section offers a basic set of use cases. The following list provides criteria to help developers understand the 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 applications from a screen reader
  • Receives information about applications 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 (for example, a person with 20/300 vision):

  • Relies heavily on the keyboard for input
  • May use a mouse, depending on the extent of visual impairment
  • May use a screen magnifier exclusively to receive information about an application
  • May use a screen reader exclusively to receive information about an application
  • May use both a screen reader and magnifier together to receive information about an application
  • 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 heavily on the keyboard
  • May depend entirely on the keyboard
  • Can receive information about the application visually

A user who is deaf or hard of hearing:

  • Uses the keyboard and the mouse
  • Receives information from the application in a visual form

When considering accessibility, Flex content should be evaluated using a screen reader throughout the development process. Adobe Flex 4 components were developed, tested, and optimized for use with JAWS 11 from Freedom Scientific, although older versions of JAWS (6.1 and above) are supported as well. Additional JAWS scripts for Flex are available to enhance support for specific components.

It is recommended that developers spend time learning to use the screen reader and getting comfortable with the controls. Testing for accessibility should be done regularly throughout the development process rather than postponing it to the end. At that point, it tends to be cut from the application entirely as developers identify other issues that should have been addressed earlier.

 

 

This section contains a list of best practices for the development of accessible applications with Flex 4. It is not intended to be fixed or comprehensive. It is up to developers to make decisions about individual applications and whether they meet the requirements outlined in the use cases.

Enabling application accessibility
For a RIA created with Flex to be accessible, accessibility for that application needs to be enabled. Flex applications are not accessible by default. Enabling accessibility imports the accessibility object for each component used in the application. This results in a small but nontrivial increase in the size of the resultant SWF file.

There are four strategies for enabling the accessibility of a Flex application:

Enable accessibility by default for all Flex applications
To enable accessibility for all Flex applications compiled, edit the flex-config.xml file to set the <accessible> attribute to true, as shown in the following example.

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

Enable accessibility in the Adobe Flash Builder™ 4 project properties

If you are using Adobe Flash Builder 4 software to develop Flex applications, you can inform the compiler to enable accessibility by selecting the "Generate accessible SWF file" option in the Flex Compiler section of the project properties dialog box.

Flex Project Properties Dialog

Enable accessibility using the command-line compiler
When you compile a file using the mxmlc command-line compiler, you can use a configuration variable to notify the compiler to generate the SWF file with accessibility enabled. The command-line syntax for the mxmlc.exe compiler allows the addition of –compiler.accessible (or just –accessible) to enable accessibility, as shown in the following examples

<mxmlc –compiler.accessible c:/dev/myapps/ appl.mxml> <mxmlc -accessible c:/dev/myapps/appl.mxml

 

The impact of selecting this option is that the compiler node within the .actionScriptProperties file located in the project directory will be modified to indicate the need for accessible SWF file generation.

<compiler additionalCompilerArguments="-locale en_US"   generateAccessible="true"> ...

 

Enable accessibility for an individual application
If you have not enabled accessibility for all applications by default and the application is compiled at runtime, you can enable it on an individual application by appending the query parameter and value accessible=true as shown in the following example.

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

 

Your specific development situation will determine which of the preceding methods is used. It is acceptable to provide end users with double links to the same application: one with accessibility enabled, another without. Developers may also implement a check for an assistive technology device on the client system and redirect the user to an accessible version as needed.

Using accessible components
Flex 4 includes 35 accessible controls. Each component has been thoroughly reviewed and tested for accessibility and interoperability with assistive technology. In order for a RIA created with Flex 4 to be accessible, it must use accessible components.

For a component to be accessible, it must expose role and state information according to the Microsoft Active Accessibility (MSAA) specification. Developers planning to develop their own components should plan to research and implement MSAA from the beginning to help ensure the consistent behavior of Flex components with other controls at the operating system level. Once MSAA support has been added to a control, it is important to validate that the component works with assistive technology, such as the JAWS screen reader. Screen readers rarely implement the entire MSAA spec, particularly inside of the browser, as web applications typically rely only on the 12 base controls that are included in the HTML specification. Some degree of coordination with screen reader vendors may be required if a custom-built component deviates from the approach used in the default Flex component set or a new control type is introduced.

The default set of components was developed with the intention of accelerating application development. The requirements for creating accessible custom components are nontrivial due to the complex nature of MSAA and screen reader interoperability. For this reason, developers are strongly encouraged to leverage the default Flex components whenever possible.

Controlling reading order
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, reading order may not be an issue; however, complex Flex applications may be difficult to understand unless the reading order is controlled. The following example consists of a tree control, data grid, and text area. For this application, the screen reader reads the contents of the tree control, the data grid, and then the text area. In this case, the developer should read the content using a screen reader to help ensure that the order is not confusing to the end user. The screen reader would read the title, followed by the tree control, the data grid, the text box, and the links below. Since this is roughly how one would follow the application visually, no additional attention needs to be paid to the reading order.

A screen shot of a Flex application with three components.

Figure 1. Screen shot of Flex application with three components

The second example presents a slightly more complex application. In this case, it is possible that labels associated with specific controls will not be read at the same time as the control itself. Thus users may believe that they should enter the ZIP code in a field, when in fact, they should enter their telephone number. In applications such as this one, the developer should take steps to control the reading order.

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

Applications with more complex layouts are more likely to create issues for screen reader users. Figure 2 provides a common example of an application that will create problems for screen reader users. The application uses a repeater to populate a grid. There are four rows of products, and each product has an image and a label. Since the labels and images are in separate components, they may not necessarily be read one after the other in a predictable order because of the relatively simplistic way in which Adobe Flash® Player computes the tab order. As a result, this application will likely require that reading order be controlled.

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.

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

In this case, a second method for controlling reading order is needed: Assign values to the tabIndex attribute within the MXML file. This method allows the designer to precisely control reading order. In a SWF file, there is no distinction between reading order and tab order. Contents are read by a screen reader in the order specified by the list of tabIndex values, so it is important to add tabIndex values for all objects, including all text fields and other nonfocusable interface controls.

Small section of product application

In this smaller version of the example above, you specify the tabIndex values using the following code. 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.

 

<?xml version="1.0" encoding="utf-8"?> <s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:s="library://ns.adobe.com/flex/spark" xmlns:mx="library://ns.adobe.com/flex/mx"> <s:Panel title="Your Choices"> <s:HGroup> <s:VGroup> <mx:Image width="60" height="56" source="assets/icecreampint.jpg" toolTip="Ice Cream Pint" tabIndex="1"/> <s:Label text="$42.00" tabIndex="2"/> </s:VGroup> <s:VGroup> <mx:Image width="60" height="56" source="assets/takeout.jpg" toolTip="Chinese Takeout" tabIndex="3"/> <mx:Label text="$53.00" tabIndex="4"/> </s:VGroup> <s:VGroup> <mx:Image width="60" height="56" source="assets/dovecandle.jpg" toolTip="Dove Tea Light" tabIndex="5"/> <s:Label text="$18.00" tabIndex="6"/> </s:VGroup> </s:HGroup> <s:Label text="Product images courtesy of Lavish" tabIndex="7"/> </s:Panel> </s:Application>

Providing instructions

Screen readers cannot provide many cues to a screen reader user about the layout or structure of a Flex application. As a result, it is important that applications provide instructions on 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, they may represent the first time users encounter RIAs. 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 represent new controls to users. In addition, some components may have known issues with some assistive technologies or require the use of scripts. Information about each component can be found in the next section.

The simplest way to provide instructions is through the description property for the resulting Adobe Flash application. These instructions would be read each time the end user returns to the top of the application, so it is important not to make them too long. Following 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.

 

import spark.components.TextInput; function accessibleInit() { var desc:TextInput = new TextInput(); desc.x = 0; desc.y = 0; desc.width = 0; desc.height = 0; desc.accessibilityDescription = '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.'; addElement(desc); }

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

 

For more complex instructions, it may be 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 item read by a screen reader when it encounters the application. Commonly, a hidden link or button is placed at the top of the application. This makes it easy for screen reader users to get information about the application. A second, redundant link is then placed at the bottom of the screen so that sighted users can access the same information.

Ensuring keyboard access
It is important that all controls that can be manipulated via the mouse also be accessible via the keyboard. This is intended to support users with mobility impairments as well as screen reader users. The components included with Flex and Flash Player facilitate keyboard access by automatically making mouse-defined events accessible via the keyboard. Most Flex applications are accessible via the keyboard by default.

There are two common exceptions to this rule. First and foremost are drag-and-drop events. Many users who have difficulty using the mouse will not be able to use applications. Hence developers must provide redundant keyboard events for drag-and-drop actions. For example, if a user can drag a product into the shopping cart, then pressing the Enter key may be one way to perform the same task. One means of accomplishing this is to simply use the link rather than the image component. 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, a redundant event can easily be assigned to the link that moves the product to the shopping cart.

Another important issue to keep in mind is that simply because an end user can access the controls via the keyboard does not mean it is easy to do. For some individuals, even a single key press requires effort. In considering keyboard access, developers will find it useful to 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 described in the previous section, the developer might assign the "?" key as a keyboard shortcut. This would allow the user to press the "?" key at any time and go to the help screen. To accomplish this, use ActionScript™ to create a listener object as shown in the following example.

 

Providing captions

Flex can be used to deliver high-quality Flash video content. Any audio used to deliver substantive content should include a synchronized text equivalent in the form of captions. The most flexible and straightforward means of delivering caption data in a Flash application is to stream it at runtime, which can be done with Hi-Caption Studio from HiSoftware and MAGpie from the National Center for Accessible Media. Both create a custom XML file with caption data specifically for Flash. A third tool, Captionate, can deliver either an XML file or add caption data in FLV cue points. These solutions require some additional development effort to display caption data in the Flex application.

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. Text equivalents can be provided for either an entire application or a single object within an application.

Flex applications commonly present images using only the image or loader component. To convey the contents of these components to a screen reader, a text equivalent is delivered via the toolTip attribute. The value for the toolTip is assigned as a property of the image or loader component. This content is also made visible to sighted users as they mouse over the image.

Flex image with tooltip

Figure 3. Sample application showing a tooltip used with an image

The code for this example is as follows:

 

Additional detailed descriptions of images that would not be appropriate to the sighted user can be provided using the description property for the object. This strategy might be used 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 difficult for the screen reader user to discern that the contents elsewhere on the screen have changed. Not all images require a description field though. In fact, this would make most applications extremely verbose and tedious to use.

Adding an accessible description can be achieved by accociating an accessibilityProperties object with the element, and then set the "description" properties on that object. This can be done either with ActionScript or MXML. To provide a detailed description of the image in Figure 3, for example, use this ActionScript code:

Alternatively, use MXML to set the description to the image directly:

Similar to the way in which descriptions can be added via ActionScript, developers may also choose to use accessibilityProperties.name to provide the accessible name for an object.

Flex 4 provides special properties that allow you to set an element's name or description directly, without having to create an accessibilityProperties object first. These properties are accessibilityName and accessibilityDescription. The code below illustrates the use of accessibilityDescription.

Using color wisely
Color selection in Flex content should take into account users with color deficits and low vision. This means that color should not be the sole means of providing information. For example, never say, "Click the red button to move forward and the green button to move back." It is acceptable to refer to color, but an additional indication should be used at the same time. For example, add a reference to position as well such as, "Click the red button on the right to go forward and the green button on the left to go back."

A second issue related to the use of color is to ensure that foreground and background colors are sufficiently contrasting for readability. One way to determine readability is to consider if the colors would be readable if the application were displayed on a black-and-white screen. Colors that lack contrast can make it challenging to read elements on the page.

Focus visibility is often a color-related issue. The default focus in Flex components is sometimes too light for some users. Flex 4, however, provides a focusThickness style that can be applied to make the focus more visible to users.

To accelerate developing accessible applications, Flex 4 includes 35 components with support for accessibility built in. These components automate many of the most common accessibility practices, such as providing text equivalents, labeling controls, and promoting keyboard access, and help ensure a consistent user experience across rich applications. For detailed information about each component, including user instructions, known issues, design considerations, and AT interoperability information, see the Flex 3 Developer's Guide.

Accessibility is an issue of ensuring the individual experience, not merely complying with standards. Guidelines for accessibility can only be helpful if they lead developers to improve usability in their applications for people with disabilities. The best way for them to do so is to include people with disabilities in the development process through formal usability testing for large applications. Alternatively, developers can simply invite others to review early builds of the application and comment on it. Feedback at this stage can be especially useful. The beauty of creating accessible applications with Flex is that it already addresses the most difficult aspects of keyboard and screen reader access in its components. So enabling accessibility in rich media has never been easier.

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