Last time <http:www-106.ibm.com/developerworks/library/us-cranky1.html>, we showed you how to make your site as inaccessible as possible. Here, we'll take a look at the pitfalls of JavaScript. JavaScript can be used as an enhancement, but too often it ends up rendering a page unusable to people who don't run it. There are a number of good reasons why it might not be running in a given browser, and pages should never depend on it.
MSG is a "flavor enhancer," with one slight problem -- some people are allergic to it. Most people don't seem to care much either way, but a small number of people seems to have bad reactions to it. If you ask people in the industry who sell it, they'll tell you it's quite safe, but there are others who claim that it's potentially lethal to some (very, very few) people.
JavaScript is a "Web enhancer" with one slight problem; some people don't run it. Probably by now, a majority of Web users have some variety of JavaScript available to them, but a fair number either don't have one available, or have disabled it for one of a number of reasons. Many Web design tools use JavaScript by default, but a lot of style guides recommend against this.
A given visitor to your site may not have JavaScript available for a number of reasons. These can be broken down into software issues and policy issues. Some users may, for one reason or another, be unable to run JavaScript; others may choose not to.
Software issues revolve around the choice of browsers. It's easy to recommend a current browser, but that may not work for the user. The browser in my PDA can't do JavaScript, but I can browse a lot of sites from it anyway. Furthermore, if JavaScript is unstable or has security bugs, in certain browsers it's effectively unavailable. (The example I like to use is that, as of this writing, the most recent version of Netscape that's available for my primary desktop system can be used to create a remote access vulnerability, if I actually run JavaScript.)
Policy issues come largely from the potential security and stability issues mentioned above. Both individuals and companies may establish policies against the use of JavaScript, even with browsers that have support for it. These policies make JavaScript non-functional as surely as an older browser does -- and eliminate any hope of "fixing" the problem by putting a little button telling people to "upgrade to a newer browser." (Indeed, there's something offensive about being told to upgrade to a browser that's two years older than the one I use.)
One of the reasons people object to JavaScript, rather than merely ignoring it, is that some Web pages require it. Usually, this isn't a conscious decision made by anyone in particular; it's just carelessness.
One of my favorite examples of this is a clever little splash page I saw recently. If you had JavaScript, it redirected you to the JavaScript version of their page; otherwise, it redirected you to the plain version. Why would this be bad? Because the redirection was entirely in JavaScript, and if you didn't have JavaScript, it just didn't work.
A particularly annoying variation of this is to use JavaScript as the only way to follow a link. The HREF value is just #, and the URL is provided through a JavaScript onClick= tag. Thus, if you hold the mouse over the link, the browser doesn't show you the URL it will go to when you click...and if you don't have JavaScript enabled, the link is just broken.
The first time I found a menu where every link was just a link back to "currentpage#," I didn't know what to make of it. Strangely, I've seen this exact same code multiple times; this suggests that it's not just an isolated burst of insanity, but a "technique" someone has recommended -- or perhaps some exceptionally psychotic software vendor wrote the code and is sharing it.
Many sites use JavaScript for form validation. This sounds great -- you make the user's browser do all the error checking, so your CGI doesn't have to. Unfortunately, there's a small problem: The user can, if the user wishes, create a new HTML page, with the same form...and with no error checking. Will you accept that form submission? If so, you're either going to destroy your database, or do the error checking yourself. Anyway, if you have to do the error checking yourself, why not just make the form work without JavaScript? The only advantage of "forcing" people to use it turns out not to really exist.
Since I first wrote this, I've seen a news story about e-commerce sites getting abused by users who alter forms to set new (low) prices on goods they wish to purchase. If the sites had done their own internal validation of data, rather than relying on the user's browser, this might never have happened.
One page I recently visited used about eight pages of JavaScript (and VBScript!) to figure out the platform I was running on. The JavaScript, with huge amounts of nearly-duplicated code, tried to determine which version of which browser I was using, so it could figure out how to query for an OS version. After all, I was buying a software package, and it needed to know which version to let me download.
The page it was on was dynamically generated, and the non-JavaScript data on it contained, among other things, the serial number of the software -- a serial number that contained either an "M" or a "W," depending on whether the software was the Macintosh or Windows version.
In other words, the JavaScript was totally irrelevant. A substantial amount of time and debugging went into populating three variables, which were used only as hidden form input elements -- and the values that would go in those variables were known to the software that dynamically generated the whole page.
I have seen any number of pages that use JavaScript just to create a submit button for a form. No special evaluation, no nothing. Why not just use a regular submit button? Similarly, lots of sites have pop-up menus that use JavaScript to automatically "select" a particular option. This creates a new problem; what if I look at the menu, and end up not liking any of the options? Still, once again, there's no reason not to provide a plain old submit button.
In summary, JavaScript should always be optional for users. Dependency on it cannot improve a page; it can only cripple it. In particular, be wary of the possibility that your tools will be creating a dependency when you're just looking for an enhancement. Enhancement is harmless and will not generally offend people. Don't tell people they have to use JavaScript to view your page; it's rude, and it won't win you any customers.
This week's action item: Turn off JavaScript, flush your cache, and try to navigate your company's page. Is it usable? While you're at it, get a list of the security problems that have been found in the scripting implementation you use. (This may be hard, but it can be very informative reading. Are all of them fixed in the version you're running? Probably not!)
Peter Seebach has been having trouble navigating through badly designed pages since before frames and JavaScript existed. He continues to believe that, some day, pages will be designed to be usable, rather than being designed to look impressive. You can reach him at crankyuser@seebs.plethora.net.