The greater part of last year i was heads-down-busy developing the EventManager Game which i had the pleasure to build at Liip for Postfinance. EventManager is an educational but fun game, that approaches topics such as budgeting, financing and investing in a modern way (read: not boring you to death).
Today i want to talk to you about the new iteration of the game that we just released a couple of weeks ago. What is new you ask? How about: Accessibility! And not just any form of accessibility – the Game has earned the AA+ Certification from Access For All (their highest certification grade conform to WCAG 2.0).
In this two-part blog post i will cover the technical, as well as overall aspects of this endeavour. This first part will cover a brief history of accessibility within the Flash Platform and its current state and hopefully useful insight if you are considering to add accessibility to one of your projects.
Thanks to Adobe (and of course Macromedia back then), the Flash Platform has been sporting accessibility features since Macromedia released Flash MX back in 2002. For those that remember, this used to be Flash Player in version 6 and just introduced the Vector Drawing API (ahh, nostalgia.. but i digress).
Over the years obviously the feature set has vastly improved and Adobe (rightly so) can be proud of the level of accessibility that the Platform has today, since it allows you to:
As you see, there is really not much to wish for left here. In fact, if you use the Flex Framework, all these functionalities and features are just a step away from you. But that’s not all, Adobe has made it quite simple to build your own components within the flex framework, that can with little work, implement the accessibility layer. If that wasn’t enough you even have the capability to manually trigger an event to tell attached screenreaders that something has changed within your application.
For us developers, this means that we have the tools and capabilities to fully fullfill the guidelines proposed by WCAG 2.0.
One of the “limitations” when it comes to the Flash Platform and accessibility, is that it’s only available for the Windows Platform.
There have been many voices that critisized Adobe for “only” implementing the Microsoft Active Accessibility (MSAA) API, yet to this day it seems that it is the only documented and standardized API out there. Also it is to be said, that the most popular and wide used screenreader applications have their home only on the Windows Platform.
Question: So, since the Flash Platform supports accessibility so well, how come there are only a few accessible flash sites out there?
This question is usually met with one of the following answers:
ANSWER: Costs for implementation too high
There is no denying that implementing accessibility into a flash application is a high cost investment, if you do not already have a developer with prior such knowledge.
This has multiple reasons. Depending on your application it will require an entire different approach than just the straight forward making «Your-Standard-RIA App» or «Form-based GUI App» accessible. Which obviously, unless you have done it before will require tinkering, information gathering, experimenting and lots of testing. Hence, it will take time and thereby cost money.
ANSWER: Too difficult & lack of documentation
I have good and bad news. The good news is if you are considering making your RIA accessible, rejoice! Most of the information / documentation on accessibility for the Flash Platform is actually directly aimed at the Flex Framework and at RIA development.
And here is the bad news: if you want to make something completely custom – like a game – accessbile, make sure you have enough time at your hands, you will need it :). But since you are reading this, hopefully i’ll be able to provide you with enough information to ease your pain :).
The main problem lies not in the fact that implementing is difficult or complicated, it’s the fact that real in-depth documentation is either missing, hard to come by and that examples usually only cover little ground. So the difficulty of implementing accessbility really only comes from the fact that you will have to invest lots of time into testing and debugging.
ANSWER: No time / No money within the project
This really is a convergence of the previous two points. Lack of knowledge and the possible cost of implementation, compared to the percentage of users who actually will benefit from that step, leads often – and here we have to be honest to ourselves – to the quick dismissal of accessibility within projects.
ANSWER: What? Flash is accessible?
Yes genius, have you missed the memo? In fact a few years back when i took Macromedia’s Certified Flash Developer exams there was already a huge part dedicated to accessibility within the exam. Go read up, right now!
Adobe followed in Macromedia’s footsteps and continued to improve accessibility, updating the accessibility features once more in their latest Flex 4.0 Framework and implementing their entire accessibility layer into the freshly released AIR 2.0.
Coming back to our topic at hand, for EventManager i was confronted with a game that had many requirements.
The game’s flow for example, does not allow a regular tab order, it just wouldn’t work. There were also many interactions that would take place without any prior user action and those had to inform the player obviously about what is happening.
Depending on where you were in the game or what you wanted to do, the keyboard had to apply a different layout/scheme that is tailored to the task at hand. For example, when you are on the eventgrounds, you need to be able to place/manipulate constructions, which obviously has an entire different control scheme than for example having to bid on an artist in the auction part of the game.
To make the matter worse, the game has a strong mix of pure flash elements and flex components. Oh, and everything had to be multilingual of course :)
Keyboard accessibility was pretty clear from the start. We needed a class that allows us to set a specified keyboard layout/scheme to be active when we needed it.
For user-interactions, it was generally agreed that a context-menu would make most sense and thereby should be used for building constructions and general interaction with the eventgrounds in the game.
When it came to implementing screenreader accessibility the concept had to change a couple times, obviously here the lack of knowledge was a problem and forced me to try out various things until finally finding a working and valiable solution.
At this point i would like to extend my most grateful thanks to Adobe’s Accessibility Evangelist (congrats on the new position!) Matt May , he was of incredible help and was able to give me just the right hints, that helped me resolve some key issues that were plaguing me during my quest for accessibility.
The final solution can be broken down into three essential parts:
I’ll be covering all the technical details and attempted approaches in the second blog post: Flash & the Quest for Accessibility – Part #2.
I’ve invested countless hours in information gathering and hunting down resources concering accessibility and possible ways of implementation so that most screenreaders are supported.
Sadly, as it turns out, supporting all available Windows screenreaders seems to be impossible (see these tests). Thereby i concentrated on JAWS and ZoomText since these two applications seem to be the most widely used, when it comes to assistive technologies.
The resources gathered throughout the project that were useful are publicly available via my delicious account. They have notes as to what information was useful and/or if parts of the information was incorrect or not valid anymore.
All in all, getting the chance to implement accessibility in such a big flex application was an incredibly rewarding experience in multiple aspects.
Getting the chance to actually implement accessibility was a great, allbeit, at times nerve-wracking experience that gave me new and invaluable knowledge.
The most rewarding aspect of the entire project though, to me personally, was to receive the excited feedback from our targeted end-users audience. A big thanks also here to Access4All, the entire team at LIIP and everyone else involved in this big effort and of course to Postfinance for giving us this great opportunity.
Feel free to leave comments or get in touch with me if you have any further questions about flash, flex or accessibility.
Hi Sandro,
You write that “to this day [MSAA] seems that it is the only documented and standardized API out there”.
In what sense is MSAA “standardized”? Are you aware of the GNOME Accessibility API (ATK API and AT SPI), IAccessible2 (Linux Foundation released version 1.2 on 21 June 2010), Microsoft UI Automation, the Macintosh accessibility APIS for Carbon and Cocoa and the Java Accessibility API (not to mention the several accessibility APIs for mobile platforms that were released in the last two years)?
Hi Christophe,
ok, “standardized” may have been the wrong word and Microsoft UI Automation is actually the successor to MSAA. What i meant to say is that MSAA is probably the API that has been available the longest and up to this day was the most reliable to implement. I’m not so much aware of all the different implementations on OSX and Linux since i hardly use these Platforms except for the occasional testing of cross-platform content. But your comment actually highlights quite well the need for a really “standardized” api that could be used across platform/devices.
What i was trying to say is, i understand that Adobe only implemented MSAA so far as all the other accessibility apis where evolving.
Here’s hoping that a future version of the flash player will gives us cross-platform accessibility features.
Hi Sandro,
Thanks for the clarification.
Standardising the accessibility APIs is apparently the goal of ISO/IEC 13066, a multipart standard/specification/technical report (not each part may end up as an actual standard) being discussed within ISO/IEC SC JTC 1/SC 35 (User interfaces). Part 1 should cover requirements and recommendations for interoperability, part 2 the Windows accessibility API, part 3 IAccessible2, part 4 the Linux accessibility API; part 5 has been reserved for a future Technical Report on the Apple Macintosh OS.
IAccessible2 has a lot in common with the Java Accessibility API and the GNOME Accessibility API because the goal was more or less to bring Windows capabilities up to the level of ATK/AT-SPI.
I don’t know if their will ever be a cross-platform accessibility API. (Well, Microsoft says that UIAutomation is cross-platform because it works on Windows Vista and Windows 7 and there is an ATK bridge.)
Thanks for all the information Christophe.
I’m not suprised that MS claims Windows Vista < -> Windows 7 to be cross-platform. Very entertaining though :).
Oh, I forgot ISO/IEC 13066-6 for the Java Accessibility API.
Congrats for the nomination for Master at the Best of Swiss Web Awards: this outstanding educational game would be a worthy winner – keeping my fingers crossed!
Cheers!
Andreas
[...] # # More Play Press Releases Canal Winchester, OH (PRWEB) July 16, 2007 Newt's Playing Cards has published a deck of Buckeye Play…lklore and even how to plant your own buckeye [...]