For the last couple of weeks, I’ve been focused entirely on understanding the accessibility capabilities of Flash Player. My goals were two-fold. First, I needed to learn as much as possible about the documented and undocumented APIs available to ActionScript (The “undocumented” link purposefully leads to a page that doesn’t exist). Second, I wanted to use my findings to create a list of feature requests so that Adobe can improve accessibility support in future versions of Flash Player.
The following list compiles, in no particular order, what I felt were the more important missing features related to Flash Player’s accessibility. After each description, I link to the relevant feature request in Adobe’s public bug database. Please vote!
-
Flash Player isn’t accessible on a Mac
For a cross-platform runtime, it’s a little troubling to see that Flash Player on a Mac can’t communicate with a assistive technology. Mac OS X 10.4 and 10.5 both include a built-in screen reader, called VoiceOver. With two versions supported by the base Mac operating system (it’s not an addon), I sincerely hope support for VoiceOver is a priority for the upcoming Flash Player 10.
Feature Request: Support Accessibility API on Mac OS X
-
The AccessibilityProperties class doesn’t support roles
Adobe recommends that we use the documented class, AccessibilityProperties. This class provides a simple API for many properties used by screen readers. One property it doesn’t expose is the role of the accessible object. Everything seen by a screen reader in Flash Player is a “graphic”. I’d love to be able to specify that an object is a button or a list.
WAI-ARIA roles are recommended for UI controls created in HTML. I think this would be a great standard for Adobe to use as a basis for Flash Player’s accessibility.
Feature Request: Support for roles in AccessibilityProperties
-
AccessibilityProperties doesn’t expose the display list hierarchy
This one’s a little more abstract, but the hierarchy of accessible objects on the display list isn’t made available to accessibility clients when you use AccessibilityProperties. If I make a TabBar control, I cannot specify that individual tabs are children of the TabBar.
I can’t declare the ultimate importance of this feature because I’m not an experienced screen reader user, but I definitely noticed the difference while testing with Microsoft’s Accessibility Explorer. When viewing native Windows applications, it displays a nice tree of objects that one can navigate. In a Flash Player application, I only saw a flat list of objects. At the very least, if this hierarchy isn’t important for screen reader users, it helps a developer to organize a very complex application for debugging purposes.
Feature Request: Support for Object Hierarchy in AccessibilityProperties
-
Some accessibility APIs in Flash Player are undocumented
As I stated previously, Flash Player has undocumented accessibility APIs. The Flex components and the Flash CS3 components both uses the undocumented class
flash.accessibility.AccessibilityImplementation. It appears this class is based on the IAccessible interface from Microsoft’s Active Accessibility (MSAA).Unfortunately, Adobe’s implementation for ActionScript is incomplete because it doesn’t provide all the same functionality available to developers using MSAA. Additionally, this API is obviously platform-specific, so future Mac support will likely need to be handled very differently.
I believe that Adobe needs to do one of two things.
-
AccessibilityImplementation should be fully documented. If Adobe wants the developer community to be able to build complete components of the same quality as the Flex framework components, we should have access to the same APIs.
-
Alternatively, if Adobe believes that we shouldn’t be using the AccessibilityImplementation class (the reasons I stated above are good reasons why we shouldn’t use it), they should not use this API themselves. It looks unprofessional. If that’s the case, substitute a better API that will allow cross-platform development and more complex controls. This may be possible with some simple additions to the existing AccessibilityProperties class.
Feature Request: Accessibility implementations use undocumented APIs
-
For more information about the limitations of Flash Player’s Accessibility features, see Niqui Merret’s blog post from last year, Accessibility in Flash bug and issue list. For information related to web accessibility and laws in various jurisdictions around the world, see Policies Relating to Web Accessibility. In time, accessibility laws will become stronger, and it’s important that Flash Player provides better support early so that developers can prepare.
With respect to accessibility on mac–you really have to blame Apple here I think. All the information I’ve ever heard on the subject points to the fact that practically everyone who has such needs uses Windows as Mac just isn’t there. The “Voice Over” thing is new to me–but I’d be interested what the numbers are like.
The general point you make, however, that Flash could get better is well taken. However, as a developer I don’t know how much it would help if Adobe improved this. I’ve never had a client say they even want to consider accessibility. There’s plenty of blame to go around–that’s not my point… just that, for whatever reason, there’s not much demand that I can see for it. Maybe this bad for Flash?
…yet. There will be, guaranteed.
At my previous employer, Business Objects, we built a dashboard design application called Xcelsius that used SWF as an output format. Accessibility was always the first requirement from any company that had interactions with the US government when the sales folks at BOBJ gave them a call. Software used by government agencies must provide accessibility support today. They won’t consider your app until it supports screen readers. In other countries, it’s not just government agencies; businesses must support accessibility too. I believe I’ve heard that Japan has some of the strongest policies in this area.
In the last few years, I’ve seen several successful lawsuits against companies that don’t make their websites accessible. Target was one company that got in trouble because a disabled person was unable to use the website to buy something online. If you work or contract for small companies now, you’ll probably be safe for a little while, but larger corporations will begin feeling the heat very soon if they haven’t already.
Personally, I feel the same in many ways, Phillip. I rarely get projects that require accessibility, and if it’s mentioned, it’s a “nice to have”. However, time and again, I hear about accessibility laws and the frustrations that disabled users have. I want to help them by creating accessible Flash content and I know I will need to do it eventually. I’d rather Adobe get things rolling now so that they’re ready when accessibility becomes as common a requirement as the ability to skin and style controls.
Thanks for the rundown. Going right into my delicious bookmarks so I can refer back when we finally have to start addressing accessibility in our applications at work.
You’ve hit bugs.adobe.com, right?
Background info:
o Mac has had text-to-speech for awhile, but last I heard there weren’t hooks accessible to browser plugins.
o (For Mac text-to-speech, I’m unclear on the user case… are you thinking of the blind on the Mac, or your own evaluation of their experience, or other…?)
o I hear one of the requests as “I want to specify that an object is a button, not a graphic”… did I distill that correctly?
o I wasn’t able to see the goal in the MSAA/AccessibilityImplementation part.
jd/adobe
JD,
1) Good to know. I wonder if the semi-new VoiceOver in Tiger/Leopard has added support for browsers compared to what has been available “for a while”? If not, I hope Adobe is communicating with Apple or browser vendors to ensure that this becomes available in the future.
2) I’m not sure what exactly you mean here. I’m not a blind user, but I want to make sure my Flash work is accessible to anyone, and Flash Player doesn’t allow me to do that when a blind user has a Mac.
3) Yes. I want to specify the type of UI control a display object in Flash represents.
4) There are two goals, but I desire one or the other, not both.
a) An undocumented class (AccessibilityImplementation) should be documented.
b) This class is clearly Windows-centric, and it’s not even a complete implementation. A better cross-platform API with similar features should be made available instead.
I’m still not swayed that Mac should be considered a target for Flash accessibility as mac is not a target for accessibility generally. Not trying to start a biblical war just saying.
Yeah, I totally hear you that it “will” be an issue… and the fact that it’s often difficult or impossible for Flash to compete for such projects makes me think Flash is very lacking. But, it’s also hard for me to care when my clients aren’t willing to pay for it. Don’t get me wrong–I’ve actually given papers that make good arguments for why you should make accessible sites (and for reasons beyond “it’s the right thing to do”.
If Flash were to easily and effectively support accessibility–say, even Mac too… then would anything change? Probably not. But… if they don’t improve some things (“improve” meaning make it so people are likely to use it) then it DEFINITELY won’t change.
Got it, thanks. Do you think these change-requests are suitable for bugs.adobe.com, or is another path needed?
I’m not sure on improvements to browser-plugin access to Mac text-to-speech routines… I know other folks here track it, and are interested in implementing it if possible, but I haven’t heard yet that it’s possible.
The reason I ask about the use-case is that most of those who use screenreaders have been on Windows, because of system-level support so various apps can communicate with various screenreaders. I don’t know how many people who *need* text-to-speech use Macintosh… last I heard they were uniformly on Windows. But my prior info could be outdated, or it could be that you need text-to-speech yourself for effective preview. Knowing the exact situation could help me do better lobbying inside Adobe.
tx, jd/adobe
JD, as you can see, I do have all my requests above filed on bugs.adobe.com (the Mac support for accessibility request was already there, and I voted for it). Certainly, I’d love to see someone like you champion this particular issue so that it gets more visibility before it hits the vote threshold that makes someone look at a community bug.
I believe you’re right that most, if not all, of the people who need screen readers are on Windows. It’s possible the cause of that is because Apple has provided poor APIs for such technology. I’ve played a bit the VoiceOver screen reader in Leopard on my Mac, and the situation seems to be getting better.
Personally, my primary development machine is a Mac. Obviously, I develop Flash content that will be seen on Windows too. As I developer, I don’t want to be required to switch to Windows every time I want to test my project with a screen reader. If I can do most of the testing on my Mac, that would be ideal. It’s similar to how I would build a webpage. If I can do most of the testing in Firefox, I’m happy. Once the page is nearly complete, only then do I fire up IE or Safari and ensure that those browsers render my webpage the same way.
To Phillip Kerman and those of similar view: “I’m still not swayed that Mac should be considered a target for Flash accessibility”:
The point of accessibility is that everyone can access a web page. The blind/visually impaired. Those with motricity problems. Those with cognition problems. And that, no matter what interface they may choose to use. Once you start making exceptions, you’re not accessible anymore. Adobe going for a Microsoft proprietary solution doesn’t only undercut disabled Mac users, but Linux ones, and G3 phones’, and all other non-IE – or more likely, non-Microsoft – users. (Could anyone swear that no disabled person will ever use a Blackberry?) So let’s forget the Windows/MacOS “war” altogether, and focus instead on letting everyone access a web-based solution. On that count, Adobe’s decision is a bad one. They have chosen to go for a quick solution and dropped its intrinsic purpose along the way; they will have to redo the job later on.
Besides, I can’t see a governement agency tell their web-site users: “Oh, by the way, if you are a disabled MacOS user, sorry, you won’t be able to use all our functionalities.” It doesn’t matter the number, it takes only one who complains to get them into trouble, and they don’t want that.
I develop web-based e-learning courses for internal use, where the computer environment is very controlled; yet, once in a while, a course gets demoed outside. Then I have no longer control on who use it with what browser and what computer. I can’t allow such a faux-pas as deliberately leaving someone out in the cold. So as long as Flash isn’t fully accessible, I will ignore Flash-only solutions.
(Sorry for being late to the show – and for having this post sounding a little too much like a rant.)
Found your blog while researching my own article on Flash Accessibility, figured I’d chime in, and maybe even point you in the right direction.
At least two of your points are incorrect, though understandably so as the documentation is so spotty:
“The AccessibilityProperties class doesn’t support roles”
Not true. get_accRole(childID:uint)
This method should return an MSAA role identifier.
“AccessibilityProperties doesn’t expose the display list hierarchy”
Technically true, but as the developer that’s your responsibility. Use the getChildIDArray() method to list your children, with “0” being the object itself. the ID’s correspond to the childID parameters of the other methods in the AccessibilityImplementation class.
I’m planning on writing a how-to on this, but it’s likely not an overnight thing. If you’re interested I can send you the link when done.
Jer
Jer, I was referring to flash.accessibility.AccessibilityProperties which definitely does not support roles or the display list hierarchy. The AccessibilityImplementation class does both, but very poorly.
Since AccessibilityImplementation sucks so much, I happen to like AccessibilityProperties better, even though it is seemingly limited in comparison. I found it to be much more predictable. If AccessibilityProperties supported the ability to set roles and expose children as accessible objects, it would be perfect for me, and that’s the point I was trying to make. Ideally, I would like to see WAI-ARIA roles so that Flash accessibility can finally be cross-platform and standardized instead of tied to Microsoft’s implementation.
Josh, isn’t that a bit like saying “I wish the Math class supported the trim() method”?
Getting into hierarchies, roles, default actions and states are non-trivial, and tightly bound to the controls implementation. That’s not even mentioning events. I can’t see a good way of implementing this in a generic way via AccessibilityProperties (though because I can’t see it doesn’t mean it’s not possible).
Then again, I’ve also not had any problems with AccessibilityImplementation. It’s almost completely undocumented, but it works well if you can piece together the details.
I understand and agree that Adobe and Apple should be working together to expose Flash controls to Apple’s accessibility framework. Adobe should also be fully documenting AccessibilityImplementation in Flash (as they did with Flex).
Do you know if Snow Leopard added ARIA support to VoiceOver? Last I’d heard (and it’s been a while) ARIA was partially implemented in Safari, but VoiceOver wasn’t playing nice with it.
Thanks for the discussion. Is always nice to talk to someone else that cares about this stuff in the Flash community.
Why on earth would I want the Math class to support trim()? Yes, that’s your point, but I don’t think AccessibilityProperties and AccessibilityImplementation are so different. To me, they’re just two different ways to expose things in Flash to screen readers and stuff. One is simple and great for Flash developers, the other is a Windows-specific way of doing things that doesn’t quite work as it should.
I want AccessibilityProperties to do more because it already exposes support for accessibilty in a more generic way that could easily be supported on other platforms. By adding a cross-platform set of role identifiers to it, it stays that way. I also want to make sure that complex controls can be made accessible. At times, I found AccessibilityProperties gave me better spoken results in a screen reader, but I couldn’t expose some important sub-controls. I’d be happy with just those two things, honestly. I say that if Adobe can build a set of visual UI controls to work cross-platform by finding reasonable compromises, we should be able to make the same controls non-visual by finding the same nice common ground.
I spent a month documenting AcessibilityImplementation and how it works through MSAA while working at Yahoo!… including all the bugs that made some of its functions less capable than if you tried to implement them in a native Windows app. Yes, it is still more powerful than AccessibilityProperties, but the walls it threw up were enough to frustrate me beyond belief and swear it off. Its worst fault, though, is that it’s an ugly hack in an otherwise cross-platform runtime. You know the only reason it’s there is so that Adobe can declare on their feature lists that the official Flex/Flash UI controls are accessible.