Designing for Interactions Without JavaScript

This is part seven of a series that begins here: Designing for Accessibility.

In the previous article in this series, I talked about designing for visitors who are deaf or hearing impaired. This article will talk about how your site should behave when visitors have disabled JavaScript in their browsers.

With many modern web applications relying on JavaScript to emulate desktop applications, it’s not hard to see why some companies look at accessibility as expensive — they’re looking at Section 508 1194.22(l), which states:

When pages utilize scripting languages to display content, or to create interface elements, the information provided by the script shall be identified with functional text that can be read by assistive technology.

Many developers can’t imagine how they would provide the kind of functionality required by complex web applications without JavaScript. Companies think they have to provide an expensive separate experience that doesn’t involve JavaScript.

Earlier this year I heard accessibility expert Derek Featherstone speak, and he pointed this out: if the experience doesn’t work at all without JavaScript for users without disabilities, there’s not much to be gained by providing an alternative JavaScript-free experience for users with disabilities. Section 508 is now over 10 years old, and hasn’t kept up with the changes that have occurred since it was written.

That said, there are people (with and without disabilities) who disable JavaScript in their browsers, and there are browsers and devices (including very popular touch devices) with varying levels of support, and search engines generally don’t play well with client-side scripting. So unless you’re building a very complex web application, basic functionality should always work: visitors should be able to view your content and navigate through your pages and submit your forms.

There are several schools of thought around this, including progressive enhancement and unobtrusive JavaScript, in which the basic interactions are defined first, and JavaScript layered on afterwards to provide an enhanced experience to browsers that support it. However you want to approach it, there are a few things that you as a designer can call out in your design deliverables to encourage developers to do the right thing:

  • Call out semantic structures such as links and buttons. (I can’t count the number of times I’ve seen developers use some other tag with an “onclick” event on it instead of a link.)
  • Links should go to real pages, or to an anchor on a page (you can suppress it with JavaScript, but don’t prevent it without).
  • Don’t disable the submit button for forms pending client-side validation of some field in the form.
  • Even if you’re doing client-side validation, do server-side validation anyway.

There is also a lot to be said for designing for the simplest experience first and building on that — you may find that you don’t actually need the fancy stuff.

Up next, the conclusion of this series!

December 1, 2011 · Tags: , ,

No Comments »

RSS feed for comments on this post. TrackBack URL

Leave a Reply