Avoiding Evil JavaScript

The following is republished from the Tech Times #158.

What makes some JavaScript Evil, and can beginners learn to write Good JavaScript code from day one? Cameron Adams and I have set out to write a book that proves that they can, but it’s not proving to be as easy as I’d hoped.

Bad JavaScript is worse than no JavaScript at all, because it can prevent some users from accessing your site. There are at least three groups of people that you should at least think about when adding JavaScript to the mix, and I’ve listed them here in order of increasing difficulty:

1. users that don’t have JavaScript-enabled browsers
2. users that browse without using a mouse
3. users that browse using a screen reader

Perhaps a little idealistically, I’d consider any JavaScript code that prevents one of these groups of people from accessing your site to be Evil.

At last week’s meeting of the Web Standards Group in Melbourne, James Edwards (coincidentally, Cameron Adams’s co-author on The JavaScript Anthology) summed it up very neatly:

“One person’s preference is another person’s real need. It may be that a group of users finds it easier with Ajax, but if another group of users finds it completely impossible then you’re cutting people out, and you’re doing it for basically nothing.

“I think of it as a hierarchy, basically, where accessibility is the most important thing, and usability comes next, and preference and design and aesthetics comes next. All of those things are important, but if one affects the other then you have to think which is the most important.

“And to my mind, accessibility is always the most important, because accessibility impacts on what people really need. Everything else is just preference.”

James finished his talk with an appeal to Ajax-happy developers to avoid using Ajax if at all possible unless you can do it without impacting on the accessibility of your site. James was speaking specifically about Ajax, but the same argument can be made about JavaScript in general.

So the question becomes, can we reasonably expect JavaScript beginners to write code that doesn’t degrade accessibility?

I mentioned above the three user groups that present increasing challenges to developers looking to enhance their sites with JavaScript without giving up accessibility. I want to briefly cover the specific difficulties of supporting these groups, and consider whether beginners should be expected to deal with them:

Users that don’t have JavaScript-enabled browsers

If you build a site that relies on JavaScript to provide access to certain features, or even for fundamental navigation features, you are effectively shutting out a large number of users that, for one reason or another, do not have a JavaScript-enabled browser.

Thankfully, the way to tackle this issue is relatively straightforward, and is primarily a matter of approach. If you start by building a site that works without JavaScript, and then apply enhancements using JavaScript, then the problem is solved.

We can definitely teach beginners to think of JavaScript this way, and indeed that’s what the first chapter of our book is all about.

Users that browse without using a mouse

Due to a wide range of impairments, particularly those that affect fine motor control, certain users are unable to use a mouse when browsing the web. Instead, they use the keyboard navigation features of browsers to get around on the Web.

In most cases, keyboard navigation is no more complicated to implement than mouse navigation. All it takes is a little thought, and some extra code to handle this alternative method of interaction. For example, you need to make sure users can reach every “active” element on the page with keyboard focus (typically with the Tab key), and take equivalent actions once there.

Supporting keyboard interaction as a first class citizen is something that you can teach beginners from the moment they begin writing interactive JavaScript.

Users that browse using a screen reader

Here’s where things get tricky. Currently, the best available web browsing experience for many visually impaired users is screen reader software. A screen reader sits on top of a desktop web browser, reads the page aloud, and provides additional ways to navigate within the content and to accomplish tasks like filling out forms.

Unfortunately, there are no accepted standards for how this software interprets the content of the page, and consequently compatibility with younger web technologies like CSS and JavaScript varies greatly from vendor to vendor.

That said, there are some limitations that are pretty much universal. Two of these are particularly relevant to JavaScript development:

• Screen readers do not read content that is hidden by setting the CSS display property to none.
• Screen readers operate on a static snapshot of the page, which is occasionally refreshed in a process that can neither be initiated or detected by the developer.

Writing scripts that operate under these conditions without interfering with the user’s ability to understand the content and use the features of the site can be extremely challenging, if not impossible in some cases. So what do we teach beginners about this issue, and how well can we expect their scripts to work with screen readers?

At one extreme, we can adopt the attitude that users can always switch off JavaScript if it doesn’t work well for them, and simply write scripts that work for sighted users.

At the other end of the spectrum, we can take James Edwards’s plea to heart and avoid using JavaScript altogether in order to maximize accessibility.

The approach to encourage in beginners, I believe, is somewhere in between. Make them aware of the issue, demonstrate some easy ways that you can cater for screen reader users in your scripts (e.g. by using offleft/offscreen positioning to hide elements instead of display: none), and enable them to make informed decisions about the accessibility of their own scripts.

So, that’s the approach we’re taking with JavaScript and accessibility in our book. Will every example work perfectly in all screen readers? Almost certainly not. But keyboard users will be catered for, and we’ll provide an easily-accessed alternative for screen readers whenever it makes sense to.

And you’ll pardon us for taking a little pride in writing the only beginner’s JavaScript book that gives accessibility its due from the very first page.