Accessibility and JavaScript

I probably could link to a million articles about this topic, but rather than overload you with information, I will instead try to sum up my thoughts into a short article. Web Accessibility is a movement/strategy to design websites to be usable by all web users, including the disabled and those surfing the web with technologies like JavaScript and Flash turned off. The use of JavaScript is often in direct conflict with these principles, as people rarely enhance their sites with JavaScript, instead they use JavaScript as a means of interacting with certain parts of their site. Those parts, then are considered to be inaccessible.

For those of you who build web application, such as, that must behave like a desktop application, it can be a real chore to make your site accessible. You might even be so bold as to say, "My target audience has JavaScript enabled, and if they dont, then they just cant use my product." We should all avoid such arrogance and realize that building accessible sites is the best way to be both forwards and backwards compatible, and its the best way to reach the largest audience. Plus, because so many sites are inaccessible, you can still use the fact that your site is accessible as a marketing tactic.

If you are asking yourself, "How can I make my site accessible?" The rest of this article is for you. I will focus on a 3-step techniques to fix an inaccessible site, but these steps could also be used for the site-design process.

Step 1: Planning

You must first think about your website and all the interactions you have now requiring JavaScript. For this example, I will be using the Popup system I employed on Write down the following information about each JavaScript event: how the event is triggered, what interaction your JavaScript does, and what the goal of this feature is. Probably 90%+ of the logic performed by JavaScript on your site can be done without JavaScript. For this step, a few things you will need to forget about are: animations, AJAX, and event triggers not on anchor tags.

For the Popups, we often use them as tools to inform the user that something is happening or to allow the user to edit some information on that page. They are triggered by onclick events and AJAX requests. In the Web 1.0 era users would have needed to be forwarded to another page for click events and posting alerts. So that is what I need to do, create additional site pages that do exactly what the Popups do, but without needing JavaScript.

Step 2: Building

Take all the interactions that you wrote down in the first step and build out the server-driven pages that do the exact same thing. Remove the JavaScript from your site and hook up the pages that you have written to your forms and anchors. Then drive through the site and ensure than everything works, if not a nicely as before.

In the Popup example, I will need to ensure that all user editing and alerting can be handled by server-driven pages, instead of popups. We actually, are not far away from this, as all the Popups on Mint are already server driven.

Step 3: JavaScriptification

Your site is now usable by anyone without JavaScript, but you have lost the Web 2.0 sparkle; lets put it back in. Start including your JavaScript back in, one page at a time, and revisiting each of those interactions that you originally wrote down. First ask yourself, does it still make sense to use JavaScript for this interaction? If so, then go right ahead and re-hook in your JavaScript events. Since your forms and anchors will request pages that accomplish the task, you simply need to use JavaScript to do make those same requests, intercepting the response and displaying how you originally wanted. Only users with JavaScript enabled, will experience the desktop-like version of your site, but those without will still be able to completely use your site.

For the Popups, if I was requesting a form, then I would simply make an AJAX call to the page that I build for Step 2, cut out the form, and insert it into the Popup framework. When the user posts that form, I will intercept it using JavaScript, make another AJAX call to the same place that the form would have normally posted and parse the response, showing a success or error state. For alert dialogs, I will again make an AJAX request to a page build in Step 2 and insert it into the Popup framework, then capture the okay and cancel buttons.


Thats it. Obviously, each step can take a while (depending on the site of your site), but taking the time to accessify your site will ensure that you not only support the widest audience, but also, employ the most forward thinking approach. If in the future, if you decide to move from JavaScript to another client-side technology, you have only to replace the JavaScript code, not completely rewrite your application.

For more information, checkout:

Web Accessibility Initiative
Wikipedia: Web Accessibility
10 Reasons Clients Dont Care About Accessiblity