 | Level: Intermediate Peter Seebach (crankyuser@seebs.plethora.net), Writer, Freelance
20 Mar 2001 Last time, 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.
JavaScript : HTML :: MSG : food
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.
Reasons JavaScript may not be available
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.)
Dependency vs. enhancement
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.
Gratuitous dependency
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.
Conclusion
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!)
Resources -
Last time, we showed you how to make your site as inaccessible as possible (developerWorks, March 2001).
- The W3C site serves as a "canonical" source of Web accessibility guidelines.
- Visit the IBM Ease of Use site for the latest in design guidelines, from designing for the Web to out-of-box experience.
- On a lighter note, SatireWire's review of a Cubist Web site is (while fictional) worth noting from an accessibility standpoint. The author has been to many (nonfictional) sites like this.
- Other installments of The cranky user column: Read about other Web and software usability topics.
- developerWorks Web
architecture zone: Get the Web development solutions you need.
About the author | 
| | 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. |
Rate this page
| |
