After adding accessibility support to some Flash components I’ve been developing recently, I wanted to give them a test drive. To my surprise, I discovered that Flex and Flash components that Adobe claims are accessible aren’t very usable in a screen reader environment. I have always pointed out to people who claim that Flash isn’t accessible that Flash Player supports screen readers, but it must be specifically enabled by the developer. Until I see better results (even from the official Flex components!), I will no longer make that argument.
I started my adventure by installing a trial of JAWS, the most popular screen reading software on the market. The trial will run for 40 minutes at a time, and if you restart your computer, the counter will reset and you can use it again. It’s a pretty decent solution for software developers who want to test their work. It gets kind of annoying to wait while my messenger and email programs start every time I restart my computer, but it’s better than paying $900-$1100 for a full version of JAWS.
Testing JAWS with Flex
My first test of JAWS is with a simple Flex project with a single TabBar component. I turn on accessibility for the TabBar with the creationComplete event, and I give the it three tabs, “Web”, “Images”, and “Local” (like you might see on a search engine). I start up my browser, but the screen reader doesn’t have much to read.
Flash Movie Start. Flash Movie End.
It seems Flash Player doesn’t fully support accessibility within Firefox. Unfortunate. I wonder if it’s a browser problem or Adobe’s problem? Annoyed, but still open-minded, I ran the SWF in IE instead. JAWS gave me much more information, but I found some bugs with the component almost immediately. Here’s what JAWS read to me.
Flash Movie Start. Web Tab. Active Tab. Images Tab. Tab. Local Tab. Tab. Flash Movie End.
It says “Tab” twice for every Tab that it encounters. Navigating around tabs in native Windows applications doesn’t give me that problem. It’s not a big deal, but I definitely got a good first taste of unpolished accessibility features. Next, I start testing keyboard navigation. I press the Down arrow key.
Images Tab. Tab.
So far, so good. The “Images” tab has been highlighted, but not yet selected. I press the spacebar to select the tab.
Space.
Hmmm… did it work? I can see that it did because the Tab is now selected, but a blind user only knows that they pressed the spacebar. Maybe screen readers just automatically assume that the default action is successful. Sounds potentially confusing. I’d hate to be a blind developer with buggy code. I press the Up arrow key to go back to the “Web” tab.
Web Tab. Active Tab. Images Tab. Tab. Local Tab. Tab.
Uh oh. That seems wrong. First, the behavior has changed. Instead of simply telling me that the “Web” tab has been highlighted, JAWS has decided to read off the full contents of the TabBar again. Moreover, the TabBar has the “Images” tab selected now, but the screen reader is still reporting that the “Web” tab is active. That single bug is bad enough to make TabBar completely unusable to a blind user.
I tried testing a couple more components from Flash and Flex. The most potentially embarrassing for Adobe is that I can’t seem to figure out how to press Flash CS3’s Button component. I can use the Tab key or the Down arrow to navigate between them, and JAWS will read the labels, but the spacebar won’t press them. Also, in a Windows operating system dialog, the screen reader will say “To activate, press spacebar” when a button is highlighted. Why isn’t this more consistent?
My conclusion from several tests is that the official Flash and Flex components are hardly worthy of the title “accessible”. That’s only half the battle, unfortunately. Actually trying to build a custom component that supports screen readers is even more frustrating.
Implementing Accessibility
It didn’t take me long to discover that Adobe implements accessibility for their components differently than the officially suggested methods. Outlined on the Flash CS3 Accessibility pages (by comparison, the Flex accessibility information on Adobe’s site is completely out of date), accessibility should be handled through the Accessibility panel or with the “accessibilityProperties” property on DisplayObject. It is of type flash.accessibility.AccessibilityProperties. It seems pretty straightforward to use, but I haven’t played with it much yet. Why? Well, it’s because Adobe doesn’t use it for their components, and I want to handle accessibility the way they did it.
If you look in flash.accessibility.* package in the Flex 2 LiveDocs, you’ll see two classes, AccessibilityProperties and the main Accessibility class. You might also notice that the mx.accessibility.* package doesn’t get listed at all. This package contains the accessibility implementations for each of the Flex components, like Button, List, ComboBox, TabBar and everything else. Not a big deal, I guess, but now I have to dig into my file system and open these classes directly to learn more about them. When I started exploring this area, I discovered some very strange things.
The base accessibility class in Flex is named mx.accessibility.AccImpl. The equivalent in Flash CS3 is fl.accessibility.AccImpl. All the concrete implementations, like ButtonAccImpl for the Button component or TabBarAccImpl for TabBar, extend this class. Here’s where things get intersting: AccImpl itself extends another class named flash.accessibility.AccessibilityImplementation. “But wait,” the observant reader says, “I don’t remember seeing that class in the flash.accessibility.* package when I checked the LiveDocs.” Me either. This has led me to a lot of frustration because the functions from this class that get overridden in classes like ButtonAccImpl aren’t explained very well.
Adobe has chosen to hide what appears to be the most important class for implementing accessibility in components from the rest of world. Both the Flash CS3 components and the Flex components use this class, so it must be useful and important. Why isn’t it documented? Is there some reason why I wouldn’t want to use this class in my own component framework?
Much to my dismay, I also discovered the following comment from the source code for the Flash CS3 accessibility classes:
Nivesh says: I don’t think we should document the constructors for the accessibility classes.
The reason he says that is because the user of the class isn’t supposed to instantiate the accessibility implementations directly with the constructor. Instead, there’s a static enableAccessibility() function that needs to be called. Unfortunately, from that comment alone, I can’t help but wonder what other documentation is missing from these classes. In my opinion, the documentation for accessibility is the worst I’ve seen from Adobe, and after a week of messing with their stuff, I sent in a very long feature request for “extensive documentation”, and I gave up on one of my projects until I can spend a lot more time studying screen readers and Flash Player. Nivesh, please don’t remove anything that might be useful. Developers using ActionScript 3 will look closely at Adobe’s work to help pick up best practices and ideas, and you can bet that we want to know problems you run into and learn about things that we aren’t supposed to do. Document, document, document.
How Adobe can improve accessibility in Flash and Flex
-
Update the online documentation for Flex accessibility or remove it. Information for Flex 1.5 doesn’t help me much when Flex 3 is just around the corner.
-
Give me a walkthrough or two about how to make a real component accessible. Go through it step by step as if I’m an absolute novice. The fact is, most developers using any language or environment don’t know anything about accessibility. Include information on common problems we might encounter when trying to build accessible components. I’d love to see information about how to develop an accessible component that has subcomponents that are already accessible. What if I want to use their default behavior? What if I want to ignore the default behavior completely?
-
Adobe, if you’re going to use flash.accessibility.AccessibilityImplementation, you can bet that everyone else will want to use it too. Either stop hiding it, or stop using it because it’s not fair to us. Put this class in the documentation and describe it in detail. Walk through every single function available on this class, and explain exactly what these functions do, along with how and when they will be used by the screen reader.
-
Make accessibility subjects more visible in the documentation. At the very least, try to work the subject in more often. Developers don’t think of accessibility because we don’t encounter it often enough. For instance, for every component in Flex, there’s a page in the docs that offers a short introduction, it might have a bit of source code, and it describes how the component works. Is there a description of how each component appears to screen readers on those pages? There should be.
If you made it this far, thanks for listening to me vent. Accessibility is very important, and the need for it will only become more important in time as laws get stronger. Based on my short experience trying to make Flash and Flex components accessible, I’m a little embarrassed by the obviously untested components from Flex and the difficulties of setting it all up myself. I’m no accessibility expert, though, so please add comments below if you know of some good tricks that I may have missed, or if you have any insights about the undocumented AccessibilityImplementation class. I’d love to find links to good resources for Flash accessibility too. If you’re an Adobe employee, please make sure my comments go to the appropriate audience within the company. I’d love to see improvements based on my troubles. Thanks!
“It seems Flash Player doesn’t fully support accessibility within Firefox. “
Mozilla’s working on that… more here:
http://weblogs.macromedia.com/jd/archives/2007/08/help_wanted.cfm
I went through the screenfuls of text, but just once… have you checked into how there’s a default representation of the SWF as audio, but you really gain the benefit when you add tips to the audio presentation?
Seems like you’re sometimes talking about Player features, sometimes about current Flex components… not sure I can find the main idea.
“I’’d love to find links to good resources for Flash accessibility too”
Not sure if you’ve seen adobe.com/accessibility, blogs.
http://www.adobe.com/accessibility/
http://blogs.adobe.com/accessibility/
jd/adobe
Never had to deal with screen readers yet, but I’m sure the day is fast approaching its been mentioned once or twice. It’s good to see people testing it thoroughly before I might have to deal with it.
Niqui Merret would probably be interested in your results too.
Thanks
JD, I understand that one must add extra information to Flash content to get a completely accessible experience. Obviously, Flash Player can only provide so much audio information about MovieClips and TextFields by default. Thus, you must “add tips to the audio presentation” to create a more complete experience for the screen reader.
I’m sorry if my post was confusing. The main focus was about how to add this extra audio information to user interface components. In particular, I’m most interested in the methods that Adobe engineers use because I’ve found that their methods are different than the suggested methods from the Flex and Flash CS3 documentation.
The majority of the documentation on this subject focuses on two specific classes, flash.accessibility.Accessibility and flash.accessibility.AccessibilityProperties. What I discovered while researching this subject is that engineers on the Flex framework team didn’t use these classes for UI component accessibility at all. They used a class called flash.accessibility.AccessibilityImplementation. This is a native Flash Player class (which can be seen by the flash.* namespace), but it is completely undocumented in any source that I could find. This same class is used for adding accessibility to the the Flash CS3 UI components as well.
Obviously, Adobe engineers feel that the AccessibilityImplementation class is the best choice for their components. However, since there is no documentation for it, I get the impression that Adobe doesn’t want other developers to use it. Would that be correct? Or, from a different angle, since Adobe’s official documentation focuses entirely on the other two classes, why don’t Adobe engineers use them?
Josh,
I understand your frustration with the documentation and agree that improvements are needed. For a topic as complex as accessibility, too much documentation is probably not possible. All I can promise is to carry this message forward in an effort to improve the situation.
As for your experience with the standard Flex components, I think that you’ve made some assumptions that have affected your results.
The first assumption is that you would be able to download JAWS and operate it effectively with little or no training. JAWS is a complex and often foreign environment for developers who are not blind or visually impaired to use — you can learn to use it effectively, but an understand of how the toll is used by native users is critical. I suggest that you contact Victor Tsaran who works with you are Yahoo! for advice on this.
The second assumption is that if JAWS is not behaving well it is due to issues with the Flex component or with the Flash player. There are certainly issues with different components, but it merits mention that there is a complex series of interactions that occurs between the Flash player, MSAA, and JAWS. There are challenges in delivering complex controls within a web browser window that are still being addressed by several parties, including Adobe and Freedom Scientific. The types of interactions that are needed for many controls are what is expected in similar standard desktop application controls. For a control such as a tabnavigator in Flex 2, JAWS 8 will identify it as a set of tabs, but when Flex 2 was developed JAWS 6.1 was not voicing the indication that the control was a “tab”, so that information was added to the control’s name, which now results in it being voiced twice in JAWS, which is inconvenient but not intolerable. You may be familiar with Yahoo!’s own challenges in creating an accessible TabView control and others in DHTML, which are not dissimilar to the assistive technology interoperability issues that we face in Flex.
We’ve also done work to provide scripts for JAWS to improve the voicing for many controls. JAWS users are familiar with installing scripts to improve the behavior of many applications, but this is a step that we are working to avoid in the future (the scripts for JAWS 8 are in final testing now).
I’ve posted a short demonstration on our accessibility blog showing how JAWS behaves with a simple tabnavigator component. I think that you’ll find that many of your concerns are addressed. Take a listen and let us know if you have questions.
Hope this helps,
AWK
Thank you, Andrew, for the information. I appreciate your effort. Our team has been doing some work with Victor already, and we are aware of his availability as a resource.
I saw a presentation on accessibility in Flex at an Adobe event well over a year ago, and I remember well that the presenter said that communication with MSAA and screen readers wasn’t always the easiest. He mentioned that setting up a project to follow all the “rules” to the letter sometimes just doesn’t work, and I as a developer will always need to experiment and tweak things to make sure my project will work well with JAWS and other screen readers. That’s understandable, and I have been trying my best to explore all the different options available.
My inclusion of the poor behavior from JAWS was more an afterthought. The most important part of this blog post, to me, is the usage of flash.accessibility.AccessibilityImplementation. As I said in the post above, and in my reply to JD, this class in completely undocumented, and yet it is the primary class used by Adobe engineers for implementing accessibility in UI components. I want my own components to be of the same caliber and to follow the same practices that Adobe used, and it’s frustrating that the only reference to this class is in the actual source code for the accessibility implementations themselves.
In regards to my inexperience with screen readers: yes, I’m still a bit of a novice. I’ll admit that I probably don’t know the exact usage patterns of native users. However, I am well versed in keyboard navigation within the Windows operating system, and I’ve done quite well in situations where I’ve had no access to a mouse. In my initial self-training with JAWS (before I put Flash and Flex to the test with it) I spent some time navigating various dialogs around the operating system. In general, these tests went very well, and the behavior of JAWS seemed very intuitive. There was a noticeable difference when I started enabling accessibility features on Flash and Flex UI components.
I will certainly continue to dig into the available documentation, and experiment with more of the available options. I plan to followup with more information later, especially since one of our goals on the Flash Platform team at Yahoo! is to fully embrace accessibility as part of our development strategy.
I’ve never attempted accessibility in Flex before (although I will be soon), but I have produced a few accessible components with Flash now.
So far I’ve found the components introduced in Flash MX to work well with MSAA and Jaws. For example, the checkbox component actually shows up as a checkbox when looking at the application with AccExplorer – and behaves as such, like any other checkbox in Windows.
I did encounter a problem when I wanted to customise this component however, my styling options were limited so I embarked on a quest to make my own checkbok. I soon came across the realisation that I would not be able to create something on par with the official component, because I didn’t have the tools to do so – that is the hidden classes you are talking about.
I applaud your investigation into the matter, I tried to find out how the checkbox component worked and failed miserably!
There are ways to produce accessible components using accessibilityProperties, but it’s in no way straightforward, and requires allot of experimentation.
Now you’ve brought AccessibilityImplementation to light, I wonder if the lives of developers will be made easier, as well as enabling us to produce much more accessible experiences.
Hello, the issues with screen readers are on the Adobe side.
Issues with keyboard navigation need to be resolved by plugin and browser vendors together. Mozilla needs help with implementing a proposal to change the plugin API to share the tab order and bubble unused keystrokes up from the plugin to the browser.
> Hello, the issues with screen readers are on the Adobe side.
Let me correct this. Sorry, I mean the issues of plug-ins not being accessible to screen readers at all in Firefox. I can’t speak to any of the other screen reader issues with plugins.
Actually, and that is only an issue with Flash. Other plugins like Acrobat do expose their MSAA hierarchy within Firefox on Windows.
Congrats Josh!
Yahoo! Flash Platform Team just appeared, and just I can’t wait to see how your team will bloom now with even more productive development getting more attention from both Yahoo! and Flash / Flex community.
Pingback: About Object-Oriented Programming and accessibility for Flash… « Developing jujupiter.com
Hi Josh,
I have got some samples to show you. I’ve created few flash games and made them accessible for screen reader users. You can have a look at them at: http://www.barrierbreak.com/ourshowcase.php. Also, you can get our Hangman game on Adobe’s accessibility blog at: http://blogs.adobe.com/accessibility/2006/08/
I am trying to work with what ADOBE is offering in addition with my own alternatives so as to make the e-learning courses or games as accessible as possible. Also, you can check out our blog about accessibility here: http://barrierbreak.com/blog/
I would like to know your thoughts on the games.
peace, veiky
Thanks for the links, Vivek. I’ll check them out!
Hi Josh,
Thanks for your detailed descriptions on how we can make Accessibility better. I just wanted to encourage you to file any of your Flex Feature Requests in our public bugbase. There are currently no Feature Requests for Accessibility and just a handful of deferred bugs and minor requests. If there are more customers filing bugs in this area of the product, I’m pretty sure, that it will get more focus in future versions of the product.
Thanks,
Joan
pretty soon accessability will be required.
In regards to Flex accessibility, I’ve made a feature request for more documentation:
https://bugs.adobe.com/jira/browse/SDK-15006
If you’d like to see better docs and examples in this area, please vote!
Very interesting, thanks.
Hopefully most readers will have seen this, but just to make sure…
Draft Documentation for Flash Accessibility Implementation
Hey there – I too am having a hard time making my flash files accessible, even after doing the tutorials for the files that came with CS3 on my computer – even THEIR files weren’t being read by JAWS. It read all of the buttons, in the correct order but didn’t read any of the text boxes on the page – just completely skipped them over. I build e-learning courses, some straight in flash, some in lectora, some in captivate – but experimenting in a combo lectora/flash currently and that is where this is all stemming from. If I can solve this issue – I’ll have need to use clunky old lectora for anything…except something that needs SCORM. Loved the rant….
This is a great post – very helpful, thanks! I’m working on an accessible tree control for AS2 – after hunting around, I discovered there’s a ‘magic’ _accImpl object that can be attached to any movieclip – it supports a subset of the methods available in AS3, including getChildIdArray(). The problem is, getChildIdArray() is only being called for the first level in the tree hierarchy. Sure enough, AccExplorer.exe shows only the top level of hierarchy.
This may be a limitation of Flash 8/AS2. Did you have a similar issue with your tree control, or id getChildIdArray() called for each level in the hierarchy?
I’ve found that disabling virtual PC cursor (Ins+Z, or whatever key takes the place of US Z on your keyboard, e.g. Y in the Hungarian layout) allows me to press buttons and generally use the application as if JAWS were not running.
Hello Josh,
Excellent info shared by you. I understand your frustration. I am working on Flash since many years and recently I had a requirement of a accessible elearning courseware. I was doing some R&D on accessibility and rounded up on two basic points:
– Movie clips with animations and text
– Externally loaded SWF files into teh tab order
Basically I have a navigation shell ready which loads external SWF files into it one by one and I need my whole content to be accessible. I read about restarting the screen reader from top when the page updates…..but that really is a frustrating task for a disabled user to do everytime when the page updates itself…
Accessibility is also frustrating where I have sime click and reveal types of interactivities….and the whole point is that accessibility thing sucks when your Flash content is bound to update at very short intervals….In that case development should be avooided in Flash…
Any thoughts of your would help us!
As ever,
VK
I’ve been working with Flex and JAWS – some protips I’ve found:
1. JAWS only reads correctly with Internet Explorer. Why? Because the Flex/Flash leverages the Microsoft MSAA libraries to feed object information to the JAWS reader. MS plays best with MS stuff – so yeah, it will not read with Firefox or Chrome – and really only works in a Windows environment.
2. When testing with JAWS on Flex/Flash – be sure to TURN THE VIRTUAL CURSOR setting on JAWS OFF! [ins + Z] by default – otherwise it will never read the object correctly.
3. On you 28 Accessible Flex Objects, there should be an accessibilityName propety and accessibilityDescription property – put in the audio queues to feed the JAWS reader here.
Good luck – I’ve been wrestling with this for a year now.
And oh yeah, be sure that you are compiling an accessible swf!
More information here: http://www.adobe.com/accessibility/products/flex/best_practices.html