1. Determine object role
2. Create the Accessibility Implementation class for component
3. Add accessibility tie-ins to component class
   a) Create a placeholder for the static createAccessibilityImplementation() method
   b) Override initializeAccessibility() method
   c) (Flex only) Add AccessibilityClass metadata

Determine object role

In order for the JAWS screen reader to inform the user about a particular component, it needs to know a few things about the component. Most importantly, it needs to know what the type of the component is. It does this using a predefined set of types, called Object Roles in MSAA terminology. These object roles are simply numerical values, standing for control types such as push buttons and list boxes. I like to define them as constants in my accessibility implementations, to make them more identifiable. So the first step is determining the type, which also allows you to see if you need to extend a current accessibility implementation, or start from scratch. The second step is to actually create the implementation (*whew*).

Create the Accessibility Implementation class

To create an accessibility implementation, you need to extend from a base implementation class. For Flash components this will extend fl.accessibility.AccImpl or the component’s superclass’s implementation. For Flex components this will extend mx.accessibility.AccImpl or the component’s superclass’s implementation. For instance, with Astra Carousel, I extended fl.accessibilitySelectableListAccImpl, the implementation used for SelectableList; for Astra Charts, I created an implementation from scratch, extending fl.accessibility.AccImpl.

Generally, you can pair the superclass of your implementation with the component’s superclass. And if one’s not available, start at AccImpl. The main thing to remember is that, for Flash CS3/CS4 components, you need to create the hooks in your implementation that pair it up with its corresponding component. You do this by creating a static variable and a static method:

private static var accessibilityHooked:Boolean=hookAccessibility();
 
private static function hookAccessibility():Boolean
{
     YourComponentClass.createAccessibilityImplementation =
          createAccessibilityImplementation;
     return true;
}

Notice in the hookAccessibility function, that it refers to a static variable of your component’s class. In order for this to work, you’ll need to add that static variable to your component’s class, which we’ll go over later in this article. Remember that the above code is for Flash CS3/CS4 components only–Flex will create the necessary hooks itself through the mxmlc compiler.

Once you’re hooked up, the next task is to actually set the object role you decided on. To do that, you simply set the variable role to that numerical value within the constructor of the implementation class.

Next is the hard part. All implementations will use the following methods to communicate with the screen reader, and you’ll find you need many of them to make your implementation work. However, you may not need to write custom code for all of them, as you may be able to inherit a perfectly usable method from the superclass:

• accLocation(childID:uint):* – specifies the bounding box of a child element.
• accSelect(selFlag:uint, childID:uint):void-altering the selection in the component .
• get_accDefaultAction(childID:uint):String-returns the default action of the component or of one of its child elements.
• get_accFocus():uint-returns the unsigned integer ID of the child element, if any, that has child focus within the component.
• get_accName(childID:uint):String-returns the name for the component or for one of its child elements.
• get_accRole(childID:uint):uint-returns the system role for the component or for one of its child elements.
• get_accSelection():Array-returns an array containing the IDs of all child elements that are selected.
• get_accState(childID:uint):uint-returns the current runtime state of the component or of one of its child elements.
• get_accValue(childID:uint):String-returns the runtime value of the component or of one of its child elements.
• getChildIDArray():Array-returns an array containing the unsigned integer IDs of all child elements in the AccessibilityImplementation.
• eventHandler(event:Event):void-Handles events from the master component. This essentially listens for events, and the developer must create a switch statement to call an Accessibility.sendEvent with the appropriate parameters.
• getName(childID:uint):String-returns the name of the accessible component or the name of one of its child elements.
• getState(childID:uint):uint-returns the state of the accessible component.

It’s important to note that there may be a number of other methods that need to be created for such things as telling the screenreader which child items are focused or what items are selected. Read on for some real-world examples of creating these.

Add accessibility tie-ins to component class

The last step is telling your component class to use this accessibility implementation. Actually, this is a step you can do on your components before you finalize your implementation class, because it doesn’t point to the accessibility class by name. Add these few lines of code to your class:

public static var createAccessibilityImplementation:Function;
 
override protected function initializeAccessibility():void
{
     if (YourComponentClass.createAccessibilityImplementation!=null)
          YourComponentClass.createAccessibilityImplementation(this);
}

This tells UIComponent that there may be an implementation in use, and lets your implementation class mix in with its hookAccessibility() method. If you’re using Flex, it’s a good idea to add AccessibilityClass metadata in your component class. For example, with mx.controls.Button, the following metadata is added, pointing to the implementation class:

[AccessibilityClass(implementation="mx.accessibility.ButtonAccImpl")]

Examples

Talking about what you should do is one thing, but giving you a play-by-play of my own development experience should prove more helpful.

Carousel

To create an accessibility implementation for Carousel, I determined that, because Carousel extends SelectableList, my accessibility implementation would extend SelectableListAccImpl. This saved some of the grunt work, as a few of the necessary methods were already created for me. Even the role did not need to be set, as there is no specific designation for a carousel in MSAA. Carousel is essentially a list, so I was able to keep its role as ROLE_SYSTEM_LIST (0×00000021 for the numerically-inclined). I did have to override the get_accValue method to return the value of the current item in the Carousel. Also, because a Carousel can be horizontal as well as vertical, I had to override get_accState to return the proper state information whether the Carousel was a vertical or horizontal list.

Tree

For Tree, I at first decided to create an accessibility implementation from scratch, probably because I was being stubborn. While Tree extends List, the typical ListAccImple class wasn’t going to cut it for Tree, which has a very different interaction model. However, I later realized that had to reimplement getChildIDArray, accLocation, and get_accFocus, which were already present and suitable in SelectableListAccImpl. So I decided in the end to extend that. However, there was a lot left to be written for this implementation. Tree, while it inherits from List, has its own designation in MSAA land. It is called, interestingly enough, an Outline control, designated by the constant ROLE_SYSTEM_OUTLINE. So that was the role I gave it. I reworked the get_accValue method to return the value of the current item as well as their location in the tree structure. So when the item is selected, the screen reader will read something like “Item 4 of 10″. Other things I had to do with Tree:

• get_accState was overridden to provide additional information about tree items being collapsed or open.
• get_accDefaultAction had to show additional actions of a node being collapsed or expanded.
• accDoDefaultAction needed to be reworked in order to open or close the items.
• getName was overridden to add, like get_accValue, info about the current location of the item in the tree structure.

I also found in my development that proper keyboard navigation wasn’t in place. So I added that in. That’s the great part about creating these implementations–it allows you to really test the usability of the component, not to mention helps you to find bugs.

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.

To read more about Y!OS, check this out.

No doubt you’ve heard a little something about Yahoo!’s new open strategy. If you attended Open Hack Day, you would’ve even been able to use the new Social APIs, which allow you to build powerful social applications on our Yahoo! Applications Platform (YAP).

Not to let down the Flash folks, we’ve created some nice AS3 APIs that let you easily integrate social data and create a Flash or Flex application easily in YAP. There’s even a great Yahoo! theme for Flex applications, to give you a standard look and feel right from the start.

If you’re itching to see what this is all about, it’s currently available as a preview release at http://developer.yahoo.com/flash/yos. While you won’t be able to actually use the services (sorry, coming soon), you can get a head start on learning the system and even begin developing your apps, as the code and documentation are all there for the taking. There’s even lots of source code for example applications, so you can be one step ahead of your friends.[Edit: it's now released!]

Summary of What’s Changed:

• AccessibilityImplementation is documented for the first time
• The Accessibility class is more fully documented
• Everything under the mx.accessibility.* package is documented
• Examples for accessibility implementations are now available

The main class to look at for Flash development is flash.accessibility.AccessibilityImplementation.

For Flex, the main point of reference would be mx.accessibility.AccImpl (which, in turn, uses AccessibilityImplementation). Flex component developers can look at the documentation or source code for the accessibility implementations of the standard Flex components, which all extend this AccImpl class. (For instance, mx.controls.Button uses a class called mx.accessibility.ButtonAccImpl, while mx.containers.Panel uses mx.accessibility.PanelAccImpl to enable its accessibility.)

If you’ve been browsing the source code for Flex components, you may already be familiar with these classes. You may have also noticed the lack of documentation in the source code. That should change in an upcoming release. As for now, you can stay ahead of the curve by checking out this draft.

Aquarium shows how to integrate these components in a real application and how to customize them for special use. Definite highlights are the custom skins for TabBar and Tree, a custom CellRenderer for Tree featuring interaction and animation, and the integration of AutoComplete with Tree via ActionScript. Oh, and yes, we also put in the Charts component to display current statistics. Check out the details at developer.yahoo.com/flash (”Featured App” box on the top right), and we hope you’ll have fun with it!

If you haven’t tried Pipes, definitely check it out. It has an intuitive visual interface that allows you to import and manipulate data from across the web, with zero coding skills necessary! Want to mash up all your favorite RSS feeds into a single super-feed? How about checking Flickr images against recent news articles? Whatever you create, you can export to your preferred format, ready to view in a reader or, as shown below, in your own interface built with Flash or Flex.

Once you create a pipe or try one of the many already available, you are just a couple of steps away from using that data in Flash. In the example below, we are using a simple pipe that aggregates some news feeds. First, let’s run the pipe and choose More Options > Get as RSS.

Notice that the URL you get is of the form http://pipes.yahoo.com/pipes/pipe.run?somepipe&_render=rss. That’s almost the URL you’ll use to retrieve the XML data, but not quite. For security purposes, most of Yahoo! APIs use *.yahooapis.com as the API entrypoint. So once you replace pipes.yahoo.com with pipes.yahooapis.com in that URL, you’re in business (note that there’s no crossdomain on pipes.yahoo.com, but there is one on pipes.yahooapis.com—that’s what’s working the magic.) Now, if your pipe has any parameters you need to include, just build out the URL as needed and send it along.

Here’s a really simple example in Flex that uses the pipe described above.

Please install Flash 9 to see this example.

Check out the source here.

As many new developers moving to ActionScript 3 discover, the new language is stricter and many of the shortcuts one may have taken in the past with AS2 will have certain roadblocks that must be crossed in AS3. The article tries to outline the best ways to understand the changes, work around them as needed, and most importantly, how to develop applications and websites in AS3 so that you don’t need to use these workarounds. I included several source code examples, including the progression of a simple application as I try to update it with best practices.

If you’re looking to write more flexible and maintainable AS3 code, or you’d like to help a fellow developer who is struggling with the changes from AS2 to AS3, I hope the article will be helpful.