Did a little testing today on general navigation through a sample application using the various JAWS Cursor Modes. This was necessary to get to the bottom of several inconsistencies when trying to navigate through a simple application. Testing was done using the following technologies:
- JAWS 6.2
- JAWS 8.0
- Flex 2.0.1 simple testing application
- IE
Due to yet another inconsistency with what the JAWS documentation calls them and how JAWS reads them when activated, I will be referencing the various cursor modes by how you turn them on and how JAWS reads them. The following three cursor modes are:
- + (JAWS reads ‘virtual PC cursor’, is the default mode when JAWS activates)
- - (JAWS reads ‘JAWS cursor’)
- - – (JAWS reads ‘invisible cursor’)
The following test was done to determine three things:
- Does tab navigation work as expected? No tab indices were set on any components and as such, were relying on the flat default layering of tab indices.
- Do mouse events (MouseEvent.CLICK in this test) work as expected?
- Do complex interactive components (TextInput in this test) work as expected?
Here are a few notes to keep in mind. All testing was done….:
- without Accessibility code in the flex app. Testing was not interested in read values of particular data objects. Testing was done to determine if and how JAWS takes over tab navigation.
- without JAWS scripts for flex.
- using the default swf/html embedding. Future tests will target swf object as it is now the de facto standard for embedding swf content on an html page.
- using the additional compiler argument “-accessible”.
- enabling “Generate accessible swf fil” in the Flex compiler options.
RESULTS:
JAWS 6.2
mode tabs clicks txt
(+) x √ √ (after hitting enter)
(-) √ x x
(- -) √ x x
JAWS 8.0
mode tabs clicks txt
(+) √ √ √ (after hitting enter)
(-) √ √ √
(- -) √ √ √
CONCLUSION:
For obvious reasons, it is recommended to use JAWS 8 to easily navigate through a flex application. Tab navigation in JAWS 6.2 would only navigate the expected tab order of the application when in the later two modes. In + mode, it would scan read from left to right, top to bottom, regardless of the default tab indices.
DOWNLOAD:
The source files for the test can be found in my Box.net widget over to the right or you can get them here =>
Filed under: accessibilities, actionScript, components, development, flash, flex
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.
Filed under: accessibilities, actionScript, components, development, flash, flex
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.
