Accessibility

Accessibility in the Flash Player and in products that depend on it is very important, and there is a lot more built in support for accessibility than most people are aware of. The Flash Player supports over 60 different role constants and has mechanisms for developers to set role and state information for controls, has methods for getting and setting values, and allows developers to define the accessibility location information for a control to help screen magnification tools restrict the magnified viewport, control the accessibility API focus and selection, and more.

In the documentation package linked below you’ll find:

1. Documentation of the flash.accessibility package and AccessibilityImplementation class


2. Documentation of the mx.accessibility package and accessibility implementation classes for Flex components


3. Improvements to “getting started” articles about accessibility, including a information about implementing accessibility on a sample component.

Developers have asked for this information, which has been until now not publicly shared. The documentation that we are now providing is a draft that we would love to hear comments on. To comment on this, please either log bugs on our Flex bug database at http://bugs.adobe.com/jira, orat the Flex Documentation blog entry on this topic, or you can leave comments here.

The documentation is the result of the efforts of the Flash Player, Flex, and Adobe Corporate Accessibility teams – let us know your thoughts!

UPDATE: I've modifed the files for download in response to questions from some reviewers. The zips previously contained files for accessibility that had changed in the langref, but this resulted in flash.accessibility.AccessibilityProperties apparently being removed and replaced by flash.accessibility.AccessibilityImplementation. This is not the case, both are present. Sorry for the confusion.

Download the Flash and Flex accessibility documentation by clicking on the "download now" button.

Download the "accessibility-only version of the Flash and Flex accessibility documentation.

Posted by Andrew Kirkpatrick at 10:34 AM | Permalink | Comments (7)

I spoke at the Webmaniacs conference in Washington DC last week. My speaking slides are available for download.

Posted by Andrew Kirkpatrick at 11:20 PM | Permalink | Comments (0)

Steve Faulkner wrote a good post at The Paciello Group's blog on screen reader detection (http://www.paciellogroup.com/blog/?p=61). His points are all quite fair and it is worth noting that what the Flash Player does is detect the presence of a running MSAA client, which is broader than screen readers.

This technique shouldn't be entirely discounted, however, for certain kinds of use that take advantage of the facts, which are that all Flash-reading screen readers will cause the player to set the Accessibility.active property to true, and that there are few MSAA clients that are likely to be running, although some are likely to be non-screen reader assistive technologies.

Here's a few ways that .active can be used that will benefit screen reader users, and won't be disruptive to other potential users, or may be beneficial:

1) Replacing inaccessible or difficult to use controls. If using a complex control in a Flex or Flash application, or a control that has not been improved for accessibility, you can swap that control for an equivalent one when .active is true. In one of our Flex 2 sample applications there is a slider control with two slider thumbs that the user uses to set a start and end date for the data being displayed. When an MSAA client is active, this slider is replaced with a pair of combo boxes, one setting the start date and one for setting the end date. The idea of a double-slider makes sense for UI designers, but there isn't a way in MSAA to express a double-slider, so a simple replacement here is justifyable.

2) Offering users additional options when .active is true that are likely to be beneficial is another possible use. For example, a developer might present a pop-up dialog that asks if the user wants audio description on. There would be a UI control that would allow all users to turn audio description on and off, but this would be an improvement that would be easier for blind or viisually-impaired users and that wouldn't adversely affect any other user who has a system that uses MSAA in some other way.

3) Pausing video. In a video made in Flash a developer might make the video paused when loaded when .active is true. If a screen reader user needs to navigate to the pause or stop buttons for a video while the video is playing they will find that very difficult due to competing audio tracks from the video and the screen reader. Allowing users the choice of whether video plays by default is nice for other users also, but causes more problems for blind and visuall-impaired users.

These are just examples to show that using .active to make good decisions is not impossible -- I agree with Steve's post that I would distill down to ".actve is not only set to true by screen readers". Think carefully about how you may use it.

NOTE: .isActive is an AS2 method, .active is an AS3 property - see http://livedocs.adobe.com/flex/201/langref/migration.html for migration information

Posted by Andrew Kirkpatrick at 11:40 AM | Permalink | Comments (3)

Last week, members of the Adobe accessibility team attended the California State University's "Technology and Persons with Disabilities Conference" - aka CSUN. This is a big event in accessibility each year and if you are interested in accessibility you should consider attending in 2009.

Adobe participated in four talks at CSUN:

1. IAccessible2 Development: An Accessibility API that Works for Assistive Technologies and Applications. This was a panel discussion involving IT and assistive technology companies.


2. Accessible PDF Authoring Techniques. This was a talk by Greg Pisocky and Pete DeVasto from Adobe and Brad Hodges from the American Foundation for the Blind. The presentation slides are available.


3. Rich Internet Applications with Flash and Dreamweaver. This was a talk by Matt May and Andrew Kirkpatrick discussing Flash and AJAX accessibility, related to Adobe's SPRY framework, Flash and Flex. The presentation slides are available.


4. Accessible Internet Video. This was a talk by Andrew Kirkpatrick on how you can deliver the most accessible experience in video online using Flash. The presentation slides
   are available. I'm going to post the main demonstration example shortly.

Please take a look and let us know if you have any comments.

Posted by Andrew Kirkpatrick at 09:16 AM | Permalink | Comments (2)

A group of IT and assistive technology companies have formed a group designed to address engineering challenges around accessibility issues. The group's name is the Accessibility Interoperability Alliance, or AIA. Adobe is part of this group because it is important to have improved methods to provide straightforward interoperability between IT products and assistive technology tools.

Of particular interest is the project that seeks to harmonize existing accessibility APIs such as IAccessible2 and UIAutomation. With the wide variety of assistive technologies available today, both these tools and Adobe's players need reliable and standard methods to participate in information exchanges with assistive tools. There are too many tools for Adobe's players to support directly through customization and similarly the assistive technology tools have too many IT products that they need to support so they too cannot provide custom solutions across the board. The way forward is through better and harmonized (or converged) APIs.

The AIA press release is at: http://www.accessinteropalliance.org/newsevents/pr121007.html.

The AIA group web site is http://www.accessinteropalliance.org/.

Posted by Andrew Kirkpatrick at 12:43 PM | Permalink | Comments (0)

I wanted to post a quick demonstration (using Adobe Captivate) to show how JAWS interacts with a Flex 2 TabNavigator component. This was a one-off demo - the kind I wish I could do without saying "uh" so often!

TabNavigator Example

TabNavigator example MXML source

Flex Scripts for JAWS (JAWS 8.0 coming soon)

Posted by Andrew Kirkpatrick at 11:02 PM | Permalink | Comments (9)

By now, almost everyone has heard about the IE Security Update and how it impacts ActiveX control interaction. With the release of JAWS 7.1, there are additional reasons to make sure that you add the HTML Object element in the way suggested at the Active Content Developer Resource site (http://www.adobe.com/devnet/activecontent/).

If you don't, here's an example of the badness that you'll inflict on your screen reader users. In JAWS there are two modes that you need to think about - Virtual PC Cursor mode, which allows the user to read through the document line by line or using several shortcuts; and Forms mode, which allows users to interact with controls and type information into editable controls. There are two modes because keystrokes that are needed to navigate (e.g. "f" takes you to the first form control on a page in HTML or Flash) may also be needed in a control (e.g. Frank needs to enter his name in a TextInput). When a user locates a form control in HTML or Flash, they hit 'enter' and JAWS says ""forms mode on" and the user can interact with the control.

In JAWS 7.1 there are bugs that will cause difficulties with this process. I've made a simple test file — here's what happens with JAWS 7.1 (I've put keystrokes in braces):

Flash movie start {down arrow}
Accessible Flash. Learn more at the the {down arrow}
Adobe Accessibility button {down arrow}
Resource center {down arrow}
Resource center Edit {enter - to switch to forms mode}
Enter, forms mode on. Resource center button, to activate press space bar {space}

At this point, everything is fine. The user should expect that they can now type in the edit — except that they can't. Focus has been moved to the top of the FLash content, away from the TextInput used to enter forms mode. The user needs to again navigate to the correct TextInput. This might not be a big issue if the TextInput is the first control in the Flash content, but it is a usability problem and can be a huge source of confusion.

A second issue with JAWS 7.1 is that when you tab through a web page in Virtual PC Cursor mode and tab to the not-yet-activated ActiveX control you might expect that you'd hear the same information that is available visually ("Press SPACEBAR or ENTER to activate and use this control"), but you don't. You hear nothing. If the user is aware that they've tabbed onto something they might hit ins+tab to read that item and then they will hear "Flash movie start". If the use is familiar with what is going on they might hit enter or space, but neither will work. The user needs to use the arrow keys to navigate into the flash content and if they need to enter forms mode deal with repositioning their focus.

All of this is a consequence of changes made to JAWS for version 7.1. If you enable "legacy Internet Explorer Support" in the JAWS Configuration Manager's HTML Options dialog all of these issues go away, but you can't count on users doing that.

Avoid all this by using the method recommended at the Active Content Developer Resource site (http://www.adobe.com/devnet/activecontent/).

Posted by Andrew Kirkpatrick at 01:26 PM | Permalink | Comments (0)

We released the latest version of the Flash player and the new version of Flex today, and I recommend checking them out. You can get the Flash player at http://www.adobe.com/go/getflashplayer and the free Flex 2.0 SDK is available at http://www.adobe.com/cfusion/tdrc/index.cfm?product=flex.

Flex 2.0 helps enable the creation of accessible rich internet applications, and this version adds to the level of suppot that existed in previous versions.

To support people becoming familiar with Flex and what is possible, I'll be posting a series of small sample applications, test files, and other resources over the next few weeks. As always, please share any feedback or questions along the way...

Posted by Andrew Kirkpatrick at 01:08 PM | Permalink | Comments (1)

Testing for keyboard access is probably the first test that should be performed when evaluating the accessibility of Flash and Flex content and applications. Many developers are not familiar with the ways that users are able to interact with applications when using only the keyboard, so it is important that time is taken learn about how keyboard access should work.

For Windows, a useful resource is Microsoft’s Windows User Experience Guidelines, and in particular the section on controls (http://msdn.microsoft.com/library/en-us/dnwue/html/ch08c.asp). This document provides detailed information about keyboard access, and is worth reading. In Flex and Flash components, keyboard accessibility is designed into the components, but for developers creating new components or customizing controls it is crucial to keep the expected keyboard access requirements in mind.

A good starting point for testing keyboard access is the following basic test plan:

1. Put the mouse away. Turn it upside down, unplug it, whatever it takes to not use it.


2. Open the application or web page containing the Flash or Flex content.


3. Tab through the application without interacting with any controls. Make sure that you can follow the focus visually and that it follows an expected path.
   If you have difficulty locating the focus, this is a problem that needs to be addressed. Tools such as Inspect32 (http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=3755582a-a707-460a-bf21-1373316e13f0) can be used to assist testers in locating the focus when it is hard to see – this is just to assist in development; don’t expect your users to use this tool.


4. Tab in reverse. Shift+tab is used to tab backwards through the tab order. Occasionally there are issues in tabbing that are made apparent by reverse tabbing.


5. Tab to specific controls and check the behavior of each. For example, if you tab to a ComboBox in a Flex 1.5 application make sure that the behavior of the ComboBox matches your expectations and the documentation for the ComboBox keyboard navigation at http://livedocs.macromedia.com/flex/15/flex_docs_en/00000232.htm.
   The big challenge here is when you are using controls that you’ve made in a Flash movie (e.g. a simple tab navigator, made from scratch and possibly without much attention to proper keyboard support) or in a custom control for Flex — make sure that when you make or significantly modify a control that you determine what type of control it is and make it conform to expected keyboard conventions.


6. If the Flash content has specific keyboard shortcuts to perform functions, make sure that these don’t interfere with the keystrokes defined for specific controls. Most keystroke conflicts that I see occur when a screen reader is running, so that will be a necessary testing step for another phase of testing.

Did I mention that tab order is important?

There has been a positive change in the way that the Flash player handles tab order issue since Flash Player 8 which is that items with no tabIndex property defined are put at the end of the tab order. Prior to this version, if a single object didn’t have a tabIndex the default tab order for the player was used instead.

If you haven’t tested the keyboard access on your Flash or Flex applications yet, give it a shot. Like most testing, you’ll get faster the more you do it and be a better developer for it.

References

Flex 1.5 Documentation – see keyboard access information associated with different control types
http://livedocs.macromedia.com/flex/15/flex_docs_en/wwhelp/wwhimpl/js/html/wwhelp.htm

Flex ActionScript and MXML API Reference Version 1.5
http://livedocs.macromedia.com/flex/15/asdocs_en/

Flex 2.0 Documentation (link to be updated after Flex 2.0 release) http://livedocs.macromedia.com/labs/1/flex20beta3/00001046.html

Posted by Andrew Kirkpatrick at 09:40 PM | Permalink | Comments (4)