Yahoo! Flash (R) Blog

Creating Accessible Components in Flash and Flex

It’s been in the works for a while, but I finally had the chance to focus on making ASTRA components more accessible. Accessibility is not something many developers look at, but it’s slowly gaining ground. For many developers, even figuring out how to enable the built-in accessibility of Flash components is a job. But when you create custom components, implementing accessibility is another job entirely. Accessibility doesn’t come for free.

To begin my assessment of ASTRA components, I first had to learn to use a screen reader. I installed a trial of JAWS for Windows, which is the de facto screen reader technology, especially in regards to Flash. It’s important to note that although I develop on a Mac, I have to use Windows for accessibility testing. This is because Flash accessibility is based on Microsoft’s Active Accessibility standards, and only work on Windows machines. It can be argued that real accessibility is quite limited on the Mac, so this is more of an OS X limitation than a limitation of Flash. I also installed the Flex scripts add-ons, which are touted to provide more fine-grained info for the screen reader when using accessible Flex components.

Using  a screen reader, I quickly discovered, is a more involved process than it might seem. Your natural tendencies and habits have to be thrown out the window. For example, opening a browser window with an embedded swf, my first inclination was to use the mouse to navigate to a text input control and start typing. That didn’t work as planned. For one, a typical user of a screen reader is not going to be grabbing the mouse first thing, but using keyboard navigation to interact with an application, so I’d already cheated. Along with this, because of the way JAWS works, navigating to an input field won’t necessarily allow you to begin editing text–you must enter into “forms mode” in order to even start typing.

Once I got the basics of using JAWS down, I started to test our components. My original assumption was that the components would “mostly work” because many of them are based on lower-level components which have accessibility implementations built.

I was “mostly wrong.” A component is not the sum of its parts, in regards to a screen reader. For a component to be successfully understood by the user, it needs its own accessibility implementation built from scratch.

In the next article I’ll discuss what steps I took to create those implementations.

Find conversations: bloglines | technorati

Share: on Yahoo! My Web | on del.icio.us | digg it! | reddit!