Designing javascript for accessibility

Since the dawn of asynchronous content retrieval, javascript has played an increasingly important role in the delivery and presentation of content. A recent article in NET, however, rekindled the debate over the impact of javascript on the accessibility of dynamic websites. On the one hand, scripting can greatly enhance performance and improve the experiences enjoyed by of many of an application’s users. On the other hand, careless or excessive scripting can inadvertently exclude many users from accessing the site’s content.

For the many newer sites and applications rely exclusively on javascript for delivering content, accessibility isn’t so much a design decision as a question of whether the user-agent (browser) on the other end can interpret their code or not. For those that cannot, the obvious solution would seem to be to provide some kind of static fallback site, a solution that’s all too often sacrificed on the altar of resource limitations.

So let’s assume you have the chance to get it right. You’ve just been handed a clean slate and chartered to build a website the way it ought to be built. Should you use javascript in a critical role? The answer might vary based on your content, audience, and the experience you’re planning to create. Maybe your time would be better spent elsewhere. Estimates on the percentage of users browsing without script support typically sit around 5%, and there are many situations where catering to this small audience might not seem to make sense. Still, it’s worth considering some of the common scenarios where javascript support isn’t be available.

• The user is using an assistive technology (e.g. a screen reader) with limited or no javascript support
• The user is limited to an older browser with limited or no javascript support
• The user is (voluntarily) be browsing with javascript disabled, just to spite you.

Except for the last case, the lack of javascript support is completely out of the user’s control. Does this concern you? It should. A 5% loss in traffic doesn’t seem like much, but it adds up quickly when translated into an equivalent loss in potential customers, sales, or whatever metric you use to assess the impact of your online presence. If these customers matter to you, your best option will be to minimize (if not eliminate) any elements of your site that rely on javascript to provide critical functionality or content. And if you want to avoid rework, this should be done as early as possible in the development process.

1. Separate content from delivery. Remember Android? iOS? You’ve probably already had to repackage the site at least once to help it fit the confines of a mobile or tablet screen. Making your content available in a no-scripting situation is a whole lot easier if the important stuff is stored independently from the way that it ends up being presented.
2. Semantics: use them. We would all love to commit to WCAG and WAI-ARIA wherever they apply, but time and budget constraints have a way of turning the best intentions into half-measures. At the very least, though, title your links, provide alt-text for your images, and validate your content against the HTML flavor of the week to maximize the odds that it can be interpreted intelligibly by assistive technologies.
3. Implement <noscript>. When scripting just won’t work, it’s the ultimate fallback. In the best case, provide alternative content (e.g., a static, image-based map) when scripting isn’t available. At the other end of the spectrum, a quick notice will at least inform visitors of the content they’re missing. If you simply can’t render content without client-side scripting, the least you can do is admit it.
4. Read up. If you have time, take a moment to familiarize yourself with the Web Accessibility Initiative’s Web Content Access Guidelines (WCAG) and Accessible Rich Internet Application (ARIA) spec. Support may vary between user agents, but a little increased awareness never hurt anyone.

In closing, it’s worth remembering the positive role that javascript can play in accessible development. In keyboard-centric applications, for instance, Javascript can impart a more natural feel by adding support for navigation with the arrow keys. It can help provide fallback support for older browsers and devices, and for unusual screens. But it must be used carefully.