by Andrew Kirkpatrick

 Comments (6)


June 18, 2006

This post is subject to Adobe's Terms of Use.

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 ( 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 ( 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
    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?

The tab order is really, really important, because it not only affects the logical usage order of the application’s controls, but it also affects the reading order for assistive technologies. This means that you need to set the tab order for everything that will be read unless your application is very simple and only has object in a single vertical or horizontal group.
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.


Flash 8 Documentation – components language reference
Flex 1.5 Documentation – see keyboard access information associated with different control types
Flex ActionScript and MXML API Reference Version 1.5
Flex 2.0 Documentation (link to be updated after Flex 2.0 release)


  • By Aaron - 1:43 PM on September 4, 2006  

    I think developers should work closer together with people that use their end product. They could learn a lot more and make their product more consumer friendly. A lot of things they haven’t thought of can be worked on as well this way.

  • By AWK - 11:03 PM on September 4, 2006  

    I agree completely, but also feel that if developers can get closer to a set of keyboard behaviors that users are more likely to be familiar with, working with users can be more productive. Also, it is a cold truth that not all developers do work with users, and absent that I’d like to be able to point out a few useful resources that will hopefully result in better behaviors.

  • By Doug - 5:13 PM on October 4, 2006  

    I’m having trouble with keyboard accessibility in a movie that loads other .swf files in a placeholder movieclip. Everything on the main movie is labeled and assigned a tab order. Everything in the loaded movie is labeled and assigned a tab order as well. Once I tab into the loaded movie, I seem to be “stuck” there. I can’t tab back out to the root level. Therefore, everything on the root level is not accessible via keyboard. It doesn’t seem to make a difference whether I use loadMovie or loadMovieNum. Any suggestions? Thanks.

  • By Doug - 12:18 PM on October 10, 2006  

    To follow up to this post, it seems that the problem occurs when mixing both components and standard movieclips and buttons. Creating a simple movie with a few buttons that loads another simple movie into a placeholder works just fine. That is, the tabbing order works as expected between movies. By introducing a component, the assigned tabbing order (whether assigned via ActionScript or the Accessibility panel) is disrupted. The Focus Manager is brought into play with components. Trying to control the tabbing order of both standard buttons and components with the FocusManager class, or a combination of the FocusManager class and the tabIndex property does not work. In searching the Adobe forums, it seems that other developers are experiencing this same problem of controlling tabbing order in movies that use both components and standard movieclips/buttons. A solution may be to use one or the other, but not both components and movieclip/buttons concurrently.

  • By Parker - 11:05 AM on May 13, 2009  

    Any advice on making comboBox components truly accessible? Screen readers read mine as “undefined” and never read the combo’s contents. I’ve tried making the combo editable and of course have set the accessibilty name and description… but still nothing works.

  • By Anfisa - 11:53 AM on July 7, 2009  

    Seems like MSDN link is dead by now. But there are “Guidelines for Keyboard User Interface Design” at
    Also, “Essential Accessibility Programming Practices” at