Progressive Degradation

Everyone who has had to build a web application has come across issues with balancing accessibility needs of the product and keeping the site looking new and exciting. Even though my company is generally more on the conservative side, there are still those working within that realize that the only way to capture an audience is to “wow” them with a fresh look at the information users come to learn about and, hopefully, purchase. But what does this have to do with modals and accessibility?

Modals aren’t easily accessible!

That’s right. If you’ve worked with modals on a web page, only the most recent versions of screen readers which have begun to implement solutions that listen for Dynamic HTML manipulations such as modal windows. That, however, only takes you as a developer so far. What about the rest of the users that need assistive technologies and can’t afford to upgrade to the latest and greatest all the time? I mean, at around $900 for the software, who can really afford to stay up to date?

But what can we do about it?

It’s difficult to even tell if you have a user base using assistive technologies most, if not all, screen readers today to not alert you, as a site owner, that a visitor has assistive technologies. Luckily, there have been some individuals who have begun looking into ways to finding ways to tell this information so you can react. One of those solutions is FlashAid.  Sure, it’s been in the 1.0 release for just under 2 years, the JavaScript code on their site only works in Internet Explorer (insert your IE6 complaint here; I’ll save that for a later post) and currently only checks whether an accessibility aid is communicating with Flash, but it’s a start!

Actually, it’s a pretty fine attempt at what we’re really looking for. With a small Flash application (238 bytes) and a little JavaScript, you can effectively test your visitors to see if they’re using accessibility aids on your site. But what do you really do with this information? Well, some options I’m currently trying are to store the response from the Flash file to a cookie (set by JavaScript) and then use that cookie in any and all code that creates modals, dynamically changes and displays HTML  and to pass that information to our analytics software so we can help better our site for all of our users.

Downsides to the current implementation

It’s currently only implemented in Flash 8/ActionScript 2.0 and takes a few seconds before it can tell whether or not accessibility is in use or not on the site. This could result in the user invoking an action that opens one of these inaccessible features. The chance is pretty slim, but of course, it could happen. Placing the JavaScript code which runs this check as close to the top of the body of you HTML pages will help make that time seem less, but a balance would need to be struck since running JavaScript at the top of a page is generally not a good idea.

So, what’s next?

I’ve written some JavaScript which will add the code (with the help of SWFObject) and set a cookie that gives the result from the Flash file which expires at the beginning of the next month. It works well and even has a “debug” mode so you can simulate a PC with an accessibility aid. But it’s only the beginning. Once this piece is added to the site, we’ll be able to tell how many users have an accessibility aid installed and active, but the less accessible code within your application will need to be updated to read that cookie and react accordingly.

I plan on sharing the code once I’ve more fully tested it to ensure it works across browsers and operating systems, so come back soon!