From DHTML to DOM Scripting

By Christian Heilmann

JavaScript and Accessibility

Web accessibility is the practice of making web sites usable by everybody, regardless of any dis-abilities they might have--for example, users with visual impairments may well use special software called screen readers to read out the web page content to them, and users with motor disabilities may well use a tool of some kind to manipulate the keyboard for navigating around the web, because they are unable to use the mouse. People with disabilities form a significant proportion of web users, so companies that choose not to allow them to use their web sites could well be missing out on a lot of business, and in some countries, legislation (such as Section 508 in the US) means that any sites that provide a public service have to be accessible, by law.

So where does JavaScript come into this? Outdated JavaScript techniques can be very bad for accessibility, because they can mess up the document flow, so, for example, screen readers cannot read them back to the user properly (especially when essential content is generated by JavaScript--there's a chance that the screen reader won't see it at all!) and thus force users to use the mouse to navigate their sites (for example, in the case of complicated DHTML whiz-bang navigation menus). The whole issue goes a lot deeper than this, but this is just to give you a feel for the area.

Tip If you want to read more about web accessibility, pick up a copy of Web Accessibility: Web Standards and Regulatory Compliance, by Jim Thatcher et al. (friends of ED, 2006).

JavaScript and accessibility is holy war material. Many a battle between disgruntled developers and accessibility gurus is fought on mailing lists, forums, and in chats, and the two sides all have their own--very good--arguments. The developers who had to suffer bad browsers and illogical assumptions by marketing managers ("I saw it on my cousin's web site, surely you can also use it for our multinational portal") don't want to see years of research and trial and error go down the drain and not use JavaScript any longer.

The accessibility gurus point out that JavaScript can be turned off, that the accessibility guidelines by the W3C seem not to allow for it at all (a lot of confusion on that in the guidelines), and that a lot of scripts just assume that the visitors have and can use a mouse with the precision of a neurosurgeon. Both are right, and both can have their cake: there is no need to completely remove JavaScript from an accessible web site.

What has to go is JavaScript that assumes too much. Accessible JavaScript has to ensure the following:

  • The web document has to have the same content with and without JavaScript--no visitor should be blocked or forced to turn on JavaScript (as it is not always the visitor's decision whether he can turn it on).
  • If there is content or HTML elements that only make sense when JavaScript is available, this content and those elements have to be created by JavaScript. Nothing is more frustrating than a link that does nothing or text explaining a slick functionality that is not available to you.
  • All JavaScript functionality has to be independent of input device--for example, the user can be able to use a drag-and-drop interface, but should also be able to activate the element via clicking it or pressing a key.
  • Elements that are not interactive elements in a page (practically anything but links and form elements) should not become interactive elements--unless you provide a fallback.
Confusing? Imagine headlines that collapse and expand the piece of text that follows them. You can easily make them clickable in JavaScript, but that would mean that a visitor dependent on a keyboard will never be able to get to them. If you create a link inside the headlines while making them clickable, even that visitor will be able to activate the effect by "tabbing" to that link and hitting Enter.

Scripts should not redirect the user automatically to other pages or submit forms without any user interaction. This is to avoid premature submission of forms--as some assistive technology will have problems with onchange event handlers. Furthermore, viruses and spyware send the user to other pages via JavaScript, and this is therefore blocked by some software these days.

That is all there is to make a web site with JavaScript accessible. That and, of course, all the assets of an accessible HTML document like allowing elements to resize with larger font set-tings, and providing enough contrast and colors that work for the color-blind as well as for people with normal vision. Good Coding Practices Now that I hopefully have gotten you into the mindset of forward-compatible and accessible scripting, let's go through some general best practices of JavaScript.

Naming Conventions

JavaScript is case dependent, which means that a variable or a function called moveOption is a different one than moveoption or Moveoption. Any name--no matter whether it is a function, an object, a variable, or an array, must only contain letters, numbers, the dollar sign, or the under-score character, and must not start with a number.
<script type="text/javascript">
  // Valid examples
  var dynamicFunctionalityId = 'dynamic';
  var parent_element2='mainnav';
  var _base=10;
  var error_Message='You forgot to enter some fields: ';
  // Invalid examples
  var dynamic ID='dynamic';  // Space not allowed!
  var 10base=10; // Starts with a number
  var while=10; // while is a JavaScript statement
The last example shows another issue: JavaScript has a lot of reserved words--basically all the JavaScript statements use reserved words like while, if, continue, var, or for. If you are unsure what you can use as a variable name, it might be a good idea to get a JavaScript reference. Good editors also highlight reserved words when you enter them to avoid the issue. There is no length limitation on names in JavaScript; however, to avoid huge scripts that are hard to read and debug, it is a good idea to keep them as easy and descriptive as possible.

Try to avoid generic names:

  • function1
  • variable2
  • doSomething()
These do not mean much to somebody else (or yourself two months down the line) who tries to debug or understand the code. It is better to use descriptive names that tell exactly what the function does or what the variable is:
  • createTOC()
  • calculateDifference()
  • getCoordinates()
  • setCoordinates()
  • maximumWidth
  • address_data_file
As mentioned in previous chapters, you can use underscores or "camelCase" (that is, camel notation--lowercasing the first word and then capitalizing the first character of each word after that) to concatenate words; however, camelCase is more common (DOM itself uses it), and getting used to it will make it a lot easier for you to move on to more complex program-ming languages at a later stage. Another benefit of camelCase is that you can highlight a variable with a double-click in almost any editor, while you need to highlight an underscore-separated name with your mouse.

Caution Beware the lowercase letter l and the number 1! Most editors will use a font face like courier, and they both look the same in this case, which can cause a lot of confusion and make for hours of fun trying to find bugs.

Join us next week when we return with the rest of this chapter from Beginning JavaScript with DOM Scripting and Ajax: From Novice to Professional from Apress Publishing.
Christian Heilmann
ISBN: 1-59059-680-3
512 pp | published Jul 2006 | $39.99 US

Page 4 of 4

Previous Page
1 2 3 4

  • Web Development Newsletter Signup

    Invalid email
    You have successfuly registered to our newsletter.
Thanks for your registration, follow us on our social networks to keep up-to-date