By Kevin Yank

Avoiding Evil JavaScript

By Kevin Yank

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.

  • shmlco

    The group that doesn’t have JavaScript-enabled browsers should include those who’ve turned off jS, either on purpose or because it was turned off by selecting a higher security level.

    Much in the same vein, I have the same set of issues with sites who depend on Flash or Flex, as I tend to browse with “plugins” turned off in order to avoid all of the “rich” advertising.

  • del

    I really disagree with James Edward’s characterization of accessibility. It’s not a simple, cut-and-dry case of “needs” and “preferences.” He argues as if there’s some binary definition of what accessibility is. But there just isn’t.

    I’ll just randomly invent some possible scenario: imagine some sort of Ajax-enabled collaborative writing tool, that for whatever reason increases the productivity of the authors. They start cranking out good content and putting it on the web. As plain HTML.

    That content would exist and be accessible to everyone because because that Ajax enabled tool was out there. It’s true that not all code shops or whatever would have the resources to pull a Google and sic fifty programmers on making a gracefully degraded non-Javascript version of that app. But there is now more accessible content in the world.

    That’s evil?

  • Great write-up, Kevin! This book you and Cameron are working on sounds like a much-needed resource.

    I very recently wrote an article (on another site) about graceful degradation and progressive enhancement, with a main focus on JavaScript. The sentiments you express here are very similar to mine.

    @del: Although accessibility as a concept is a relative issue, on the personal level it is definitely binary: either I can access it or I can’t. Accessible doesn’t necessarily mean usable, though.

    Your ‘random scenario’ doesn’t hold water unless you can prove that it would be impossible to write such a collaborative writing tool without Ajax.

  • tbm

    All –

    I’m tired of listening to all this nonsense about accessibility. I have a great idea. Lets go back to using plain old green-screens; no JavaScript, no Flash, no graphics. That will solve almost all of the problems immediately.

    I have no issue with making web sites accessible, when it makes sense to do so. I don’t believe that we should impair the experience of one group of users to satisfy another, though. And I can’t agree with the distinction of ‘need’ vs. ‘preference’. Who is the arbiter of need anyway. Attempting to draw that kind of distinction is a very slippery slope, indeed.

    Finally, using the term “evil” is a very poor choice. Is it intended to imply that users of JavaScript should feel guilty about what they do? I do certainly don’t. Am I mindful of the issues that the article raises? Of course I am. But when I choose to employ JavaScript in a page, for whatever the reason, I have to be concerned with a vary wide constituency. And sometimes that means not everyone will be pleased.

    And I don’t agree with the assertion that the simplest way to avoid JavaScript is to develop without it and enhance later on. Consider this. Recently my company was required to (1) inform a user that a timeout was about to occur BEFORE it happened and give him an opportunity to request additional time and (2) the solution had to work in a no JavaScript environment. When we questioned the two requirements as being contradictory, the IT staff insisted the requirements could be met, but could not tell us how. We backed away from the project. To the best of my knowledge, there is no clean way of meeting both requirements. I forgot to add that using an automatic refresh was out, since it might interfere with software like Jaws.

  • I’m tired of listening to all this nonsense about accessibility.

    So am I. It should go without saying. No need to talk about it, just do it. :)

    I don’t believe that we should impair the experience of one group of users to satisfy another, though.

    Exactly, and that’s what Kevin is saying: don’t use Ajax (satisfying one group) if it causes accessibility problems (impairing the experience of another group).

    Your example doesn’t make sense to me. Why would it be a problem to achieve this without JavaScript?

  • Anonymous

    well, that is particularly why i don’t use javascript at all in my developments; and i balk at clients who, without justification, require it.

    it is getting more and more difficult though, with the outbreak of ajax and the so called web 2.0 – personally i feel that is a flu like virus doing the rounds on the net; every -beep- seams to catching it :eek:

    also, i feel that browser vendors, and the industry included should have javascript disabled by default, much like the plugin settings you see in modern browsers such as opera and firefox; leave it upto the user to enable javascript on a per site level if they want to.

    as for the book, well… has sitepoint not published enough? you seam to be taking over the world ;)

    dr livingston

  • Very well put. I actual try to avoid JavaScript most of the time because a lot of people are now blocking JavaScript in their browsing, I find anyway.

  • a lot of people are now blocking JavaScript in their browsing, I find anyway.

    Does anybody know the firm statistics on this? It would be great if SitePoint with all it’s traffic could shed some light on the subject. Yes, I realise their audience does not match everybody’s, but it would be nice to have some more public disclosure from popular web sites on their user stats. See for example the lower-right column on

    For those who came here hoping for something a little more usable than “you best learn this accessibility lark” here’s a practical tip: use the onsubmit property of your form tag to fire the Ajax or JavaScript handler.

    <form action="/process.php" method="post" onsubmit="return funcname(this)"<
    <script type="text/javascript"<
    function funcname(f) {
    	new Ajax.Request (f.action, { method: f.method, parameters: Form.serialize(f) ...

    That’s enough code to prove the concept. By passing the actual form properties to your lovely Ajax, even JS-disabled browsers will fire the processing script with the same data and properties. It’s up to you how pretty to make it when that happens.

  • Anonymous

    I’d like to see/hear AutisticCuckoo or anyone else’s solution to the timeout warning problem without JavaScript. It’s pretty hard to do well with JavaScript and even that can break down once you have a situation with multiple windows/tabs open in the same session.

    I don’t agree with tbm’s statements overall though. The discussion really boils down to designing web sites and apps, not a particular piece of functionality like the timeout warning. Other than the latter, I would totally recommend designing and building an app or site to work without JavaScript and then [progressively] enhancing the experience for various users after the fact. It fits nicely into iterative design, which should be a best practice itself.

  • Jim

    Most users of websites don’t know what JavaScript is and don’t care. People are looking for rich content websites that are easy to use. Change is good, and I am all for AJAX and JavaScript enabled applications and browsers. Those who want to continue to surf the web with stone age browsers, should expect problems with modern web applications.

  • Ryno

    Firstly, I should preface this comment with the fact I completely agree with the model of progressive enhancement, HiJaxing functionality, Unobtrusive scripting, equiable access for all, and of course the notion that you can’t have just accessibility without usability as well.

    However, what if:
    – There was a robust consistent way to notify screen reader users of a change of content on the screen?
    – What if the majority of web users did have JavaScript enabled by default and those that didn’t (heavily in the minority) we’re either developers, expert users or users in high security environments?
    – The focus on accessibility (equitable access, not equal) and issues with providing progressive enhancement (more time consuming to develop) in browser based web application development drove developers to use other platforms such as Flex in order to have accessible and more responsive web applications?

    If all of the above could be answered with a ‘Yes’, would this make us look at the current issues any differently, and more to the point, could we find more creative solutions in the way we develop JavaScript dependant applications?

    As someone pointed out earlier, we can’t always afford to provide full support for progressive enhancement and to pre-empt the ‘just build it without JavaScript or AJAX’, is this always a viable option in the competitive world of commercial web development?

    Looking forward to the book!

  • wwb_99

    I should add one other case of Evil javascript: using so much javascript you melt browsers and make your web app feel like s sluggish java app. For example, try the new yahoo mail. I have seen it redline one of my dual cores from time to time . . .

  • Sam Barber

    Javascript and later AJAX came about from users who are not happy with straight HTML. HTML served it’s original purpose brilliantly, but it was no Windows app. People now want their browser apps to behave more like windows apps, but HTML just isn’t capable. The problem is that while HTML became almost totally accepted by users, the feature rich clients like Java or Flash still aren’t (and won’t ever be) totally accepted.

    So our current choice is:
    1. Continue to write windows apps with all the features and functionality we want but limit to windows users only
    2. Cut out many features, speed and usability and stick with plain HTML
    3. Use Flash, Java or WPF/E and limit to users who are happy to install a plugin
    4. Use AJAX and limit to users who will enable javascript

    None of those are perfect for every situation, so for me it’s a project by project choice, but I would probably only choose option 2, where it was essential to not lock out any users, like a government iformation site. For a fun, interactive site I would most likely choose AJAX now.

    And just remember that while you feel good about yourself for making such an accessible site, there is nothing stopping the majority of users going to the similar AJAX site that does the same thing as your site but with a much better user experience.

  • You can add one more combination to the list.

    Users, like me, who have javascript turned on, but activex turned off.

    Lots and lots of object not found errors. Get’s very old, very fast.

    There are ways to accomplish what AJAX does that have existed before AJAX had a name. As in: it’s been done since 2000 on at least one site in my collection.

  • Yogesh

    First of all the word ‘Evil’ should not be used for any language. None of the language is Evil, its what we, developers who thinks in Evils way and make it Evil. Each language has its own beauty. But if we play with it, how u can expect it to work smartly.
    Regarding avoiding javascript, is completely impossible, take a sample example of form validation, do you expect the user to continuously hit the server and get those nasty server side errors. Increase your server load for validating the unnecessary checks(like required etc.)

  • Silvestr

    I absolutely agree with Sam Barber few posts above, especially with the last line.
    It’s time for a clever screen reader, that could translate into speech what the javascript should do. I know that’s a mad wish, though.

  • Themaninblue

    Quite funny Kev, this page kept crashing my browser until I turned off JavaScript :D

  • jr

    A colleague of mine surfs without css, flash, java and javascript; even graphics turned off..
    Evil! sounds like a witchhunt to me – sorry.

  • AN

    All these points are great, and you should absolutely follow these guidelines whenever possible, but it completely depends on what you’re building. Can you use Photoshop with a screen reader? Is Photoshop “evil” if you can’t?

    Developing content sites, you are publishing information, that ideally anyone ought to be able to read. But developing web applications can be a rather different animal.

    In applications, there is a continuum of possibilities. On one end you have apps like photo editing and Visio, where it might not even be clear what an accessible application for a screen reader would do. On the other end, you have simple applications like a web version of Notepad, where no real functionality would be lost by eliminating client-side interaction altogether. In between, of course, you have an enormous range of cases.

    And that’s even without considering building games: for example, web Tetris. Is it evil to build web Tetris? If you build web Tetris, are you responsible for building a version for screen readers that can post back after each action?

    As someone responsible for the web port of a Windows application, I can honestly say that I have no idea how to develop a version of my application that could degrade gracefully down to a screen reader. It would require a completely parallel coding solution. I would even be in favor of this option, except that the small company I work for can’t possibly afford this.

    I’m certainly with you in spirit, but everyone needs to realize that different types of websites have different situations and impose different practical constraints.

  • CA

    Whenever I see a blanket sweep like this I shudder. It would be great if every website (and application) conformed to accessibility standards, but the cost of doing so would render many of those websites impractical. Furthermore, many new websites relies on interactivity that would not be possible without a mouse and without JavaScript.

    I am part of a team developing an ‘Ajax’ Asset Management package. It is a spatial application, whose primary benefit is the ability for ordinary people to be able to visualize their assets. It would make absolutely no sense to provide a version that can be used without a mouse, as spatial input (x,y co-ordinates which are most logically input via a mouse) is critical for its usability.

    Finally if a user disables JavaScript, they should expect a poor web browsing experience. JavaScript is the programming platform which has enabled Web 2.0, and revoking JavaScript is akin to staying on your horse because cars are too noisy.

  • Finally if a user disables JavaScript, they should expect a poor web browsing experience. JavaScript is the programming platform which has enabled Web 2.0, and revoking JavaScript is akin to staying on your horse because cars are too noisy.

    Certainly sounds like they should expect it from you.

    So, if I want to use my JS-less phone browser to access your online shopping list app, I shouldn’t be cranky because it can’t operate without Javascript?

    Or similarly, if I disabled JS on that phone browser because I didn’t want it to connect to the server (at my expense) every time I ticked an item off the list, and the app then doesn’t work, ‘bad luck’?

    Regardless of the fact that if I’d been using the same application 18 months earlier — before it had been ‘improved‘ with AJAX — it would have run perfectly?

    Evolution, I say!

  • Anonymous

    oh my god :| i have installed flash just because of youtube type of sites(flash games are boring to me) and flash block to not see/hear dumb flash stuff on sites(i was ok with flash advertisements until they started to use sound).If something is evil its flash.

    Javascript is great and people who have javascript turn off should suffer, people who have just one eye see less so sites should all be working best in 800×600? javascript allows websites to look better and work better(not refresh with ajax). And by the way nobody cares about people that use just keyboard or some weird browsers(i found many sites that work good only in IE).
    You gave only one good argument that Javascript could be insecure, but … IE is also known for that and Firefox had more than one bug.

  • For those who want to see a JavaScript-free solution to tbm’s problem, take a look at Mike Cherim’s brilliant AutoRun at

    This handles user-settable timeouts without the need for JavaScript and it’s fully accessible. (Note that the site content, the tutorial, is still under development.)

    Javascript is great and people who have javascript turn off should suffer,

    What a friendly and considerate person you seem to be …

  • Doug

    Sorry, all that “solution” does is send HTTP headers to refresh. That is not a solution to the session timeout problem. In fact if it were pre-set (as your session duration is, it’s not user-configurable) on page load, it could be an accessibility issue because refreshing content without the user’s action is a no-no. It also breaks down in a multi-tab or child window setting just like the Javascript version. Example: Window 1 is opened and set to refresh to the logout page in 30 minutes (session length). 5 minutes later you open a link in a new window or new tab. The session is shared and session timeout is reset. But your first page will still refresh to the warning or logout page 5 minutes before the session will actually end. At least in Javascript you can attempt to cancel timers on parent windows when a child window is opened to prevent this annoyance, but there’s still not a perfect solution.

  • alec9111

    Yeah, InfoWorld also reported today that JavaScript misuse leads to the major flaw on Internet these days: JavaScript Misuse

Get the latest in JavaScript, once a week, for free.