explorers’ club

Since most components make use of either the data or dataProvider, I recommend targeting these properties as a source for binding within the each accessibilityProperties object. Here is an example that you would find within an MXML component:

<accessibility:AccessibilityProperties id="symbolNumberXChange_acc" forceSimple="true"
description="The symbol {data.symbol}, at {data.number}, exchanges on {data.exchange}."/>

It should be noted that accessibilityProperties should be implemented based on data content not based on control context. Now children within the component can target the object. Take the following example:

<mx:label text="{data.symbol}"
accessibilityproperties="{symbolNumberXChange_acc}"/>

Since the label’s accessibilityProperties is tied to symbolNumberXChange_acc, the accessible content of the component is now implementor-agnostic (not talking interfaces here). It is not knowledgeable of its implementors. By doing it this way, accessibilities can be developed in a custom component, where different layout states (and subsequent children controls) can implement the same accessibilityProperties objects. Also since binding is in use, those subscribers to binding events will automatically update their accessibilityProperties.

If the component in question is developed is an actionScript class (rather than an mxml class) then this procedure becomes more involved. It is recommended to override the setter functions of the data or dataProvider or other customer data property. Updates to the accessibilityProperties objects will take place within the setter function. It may also require that implementors of the accessibilityProperties objects be updated as well.

Caution:
Because there have been no performance benchmark tests regarding JAWS and Flex applications. it is advised that individual components developed with accessibilities do not call the Accessibilities.updateProperties(). Multiple calls to Accessibilities.updateProperties() has caused JAWS to crash or become unstable. It is recommended that the views that contain accessible-friendly components make the call to that function to limit the number of calls.

Since I have decided to plunge into the dark depths of what is Flex Accessibility Development, I will be posting my findings here and subsequent posts. This is a work-in-progress.

This and subsequent posts will be targeting the following technologies ONLY:

• Flex 2 (2.0.1 SKD)
• ActionScript 3.0
• JAWS 8.0.x
• Internet Explorer 6.0+

To get started, here are a few helpful links:

• Accessible Flex Component Development
• flash.accessibility.Accessibility
• flash.accessibility.AccessibilityProperties
• Flex Accessibility
• Creating Accessible Applications

What I have found so far:

• There is not much more documentation (aside from what I have posted above), benchmark tests, usability tests and general developmental progress regarding Flex and Accessibilities.
• I have yet to find ’standards’ pertaining to Flex and Accessibilities.
• JAWS crashes easily from calling Accessibility.updateProperties() too often.