Learning JavaScript

Accessibility and JavaScript Best Practices

In an ideal world, everyone who visits your web site would use the same type of operating system and browser, and have JavaScript enabled. Your site would never be accessed via mobile phone or other odd-sized device; blind people wouldn’t need screen readers, and the paralyzed wouldn’t need voice-enabled navigation.

This isn’t an ideal world, but too many JS developers code as if it is. We get so caught up in the wonders of what we can create that we forget that not everyone can share them.

There are many best practices associated with JavaScript, but if there’s one to take away from this book, it’s the following: whatever JavaScript functionality you create, it must not come between your site and your site’s visitors.

What do I mean by “come between your site and your site’s visitors”? Avoid using JavaScript in such a way that those who cannot, or will not, enable JavaScript are prevented from accessing essential site resources using a nonscript-enabled browser. If you create a drop-down menu using JS, you also need to provide navigation for people not using a JS-enabled device. If your visitors are blind, JS must not interfere with audio browsers; if your visitors use a cellphone with a black and white screen, or they are color blind, your page shouldn’t depend on color to provide feedback.

Many developers don’t follow these practices because they assume the practices require extra work, and for the most part, they do. However, the work doesn’t have to be a burden—not when the results can increase the accessibility of your site. In addition, many companies now require that their web sites meet a certain level of accessibility. It’s better to get into the habit of creating accessible pages in the beginning than to try to fix the pages, or your habits, later.

Accessibility Guidelines

The WebAIM site (http://www.webaim.org) has a wonderful tutorial on creating accessible JavaScript (available at http://www.webaim.org/techniques/javascript/). It covers the ways you shouldn’t use JavaScript, such as using JS for menus and other navigation. However, the site also provides ways you can use JS to make a site more accessible.

One suggestion is to base feedback on events that can be triggered whether or not you use a mouse. For instance, rather than capture mouse click, capture events that are triggered if you use a keyboard or a mouse, such as onfocus and onblur. If you have a drop-down menu, add a link to a separate page, and then provide a static menu on the second page.

After reviewing the tutorial at WebAIM, you might want to spend some time at the W3C’s Web Accessibility Initiative (at http://www.w3.org/WAI/). From there you can also access the U.S. Government’s Section 508 web site, which discusses what is known as “508 compliance.” Sites that comply with Section 508 are accessible regardless of physical constraints. At the web site, you can access various tools that evaluate your site for accessibility, such as Cynthia Says (at http://www.cynthiasays.com/); convert your nonaccessible Word or Adobe PDF documents into HTML, such as the Illinois Accessible Web Publishing Wizard (at http://cita.rehab.uiuc.edu/software/office/); and help you develop accessible content from the beginning, such as the Web Accessibility Toolbar (at http://cita.rehab.uiuc.edu/software/office/).

Whether your site is located within the United States or not, you want it to be accessible; therefore a visit to Section 508 is useful regardless of your locale.

Of course, not all accessibility issues are related to those browsers in which JavaScript is limited or disabled by default, such as with screen readers. Many people don’t trust JavaScript, or don’t care for it and choose to disable it. For both groups of people—those who prefer not to use JavaScript, and those who have no choice—it’s important to provide alternatives when no script is present. One alternative is noscript.

noscript

Some browsers or other applications are not equipped to process JavaScript, or are limited in their interpretation. If the JavaScript is not essential to navigation or interaction, and the browser ignores the script, no harm. However, if the JavaScript is essential to access the site’s resources and you don’t provide alternatives, you’re basically telling these folks to go away.

Years ago when JavaScript was fairly new, one popular approach was to provide a plain or text-only page accessible through a link, usually placed at the top of the page. However, the amount of work to maintain the two sites could be prohibitive, not to mention the constant worry about keeping the sites synchronized.

A better technique is to provide static alternatives to the dynamic, script-generated content. When you use JavaScript to create a drop-down menu, also provide a standard hierarchical linked menu; when you use script to expose form elements for editing based on user interaction, provide the more traditional links to a second page to do the same.

The tag that enables all of this is noscript. Wherever you need static content, add a noscript element with the content contained within the opening and closing tags. Then, if a browser or other application can’t process the script (because JavaScript is not enabled for some reason), the noscript content is processed; otherwise, it’s ignored.

Example 1-3 shows our original example with the addition of noscript. Accessing the page with a JavaScript-enabled browser should display it with the link labeled “First Example.” If, however, you disable JavaScript in your browser’s preferences, the page should display with the link labeled “Original Example.”

Example 1-3. The use of noscript for non-JavaScript-enabled browsers

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Example 1-3</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<script type="text/javascript">
var dt = Date(  );
var msg ='<a href="js1.htm">First Example</a>';
document.writeln(msg);
</script>
<noscript>
<a href="js1.htm">Original Example</a>
</noscript>
</body>
</html>

The example is just a simplified use of noscript; you’ll see more sophisticated uses later in the book.

As useful as noscript is, in a more complicated page, it can become tedious working with embedded noscript elements scattered about. The next section introduces an alternative approach.

Warning

A second instance in which noscript content is processed is when a browser or other application has scripting enabled but can’t work with the MIME type of the scripting block. This is also a time when the script can’t be executed, and the noscript content should be processed. However, many popular browsers such as Firefox and Safari don’t process the noscript content in these circumstances. This is an error, and one you should be aware of if you depend on noscript.

An Alternative to noscript

The more you add to a web page, the harder it becomes to maintain. If you use JavaScript to provide a great deal of functionality and then use noscript to provide alternatives, your pages could get large and complicated.

Another approach, one I recommend when you’re hiding and showing web content based on user interaction, is to design the page with static elements, and then use script to either hide these elements and provide the alternative dynamic content, or actually leave the static elements in and then provide the dynamic as an additional option.

The popular photo site Flickr (http://flickr.com) uses this technique. If you access an individual photo page as the photo owner, whether or not you have JavaScript enabled, you’ll see a link to click to edit the photo title, tags, and description. When you have JavaScript enabled, clicking on the title or the description area opens up a space to edit both; clicking a separate “Add a tag” link opens a space for adding a new tag, as shown in Figure 1-1.

Figure 1-1. DHTML and Ajax in use at Flickr

When JavaScript is disabled, clicking on the title and description doesn’t cause any change in the page, and the link to add the tags doesn’t show. Because the CSS attribute display isn’t dependent on JavaScript, the items are hidden regardless of whether or not script is enabled.

When script is enabled, by associating event handlers with page elements such as the title and description, you can use JavaScript to display the previously hidden objects when the web-page reader clicks the items.

Where I disagree with Flickr is in its message to users to the effect that if only they had a JavaScript-enabled browser, they could see such-and-such functionality, as shown in Figure 1-2. The issue is that some people may not be able to use JavaScript. Those that can but choose to disable JavaScript usually do so for a good reason, one that they’re not likely to change because of one web site—no matter how much they like that site. Adding an “if only” message to a page is similar to the old “You need to use Internet Explorer to view these pages” that became very popular at the end of the 1990s. It was a bad idea then to tell web-page readers what they should and should not use; it’s a bad idea now.

Figure 1-2. Flickr page with JavaScript disabled, and the “if only” message

You might as well put up a “Wow, you’re really an annoyance” sign because that’s basically what you’re saying.

Using Your Browser and Other Developer Tools

When JavaScript was first implemented, acceptance was slow because there were no script debuggers or development tools for the language. Now, though, most browsers have built-in JavaScript consoles or other tools to simplify the JavaScript development and debugging process.

Firefox has a JavaScript console listing errors and warnings, accessible by clicking a symbol (either a stop sign for an error, a warning triangle, or a conversation bubble with a small i) in the toolbar or by clicking JavaScript Console in the Tools menu. This console provides debugging information for the JavaScript for each page, and persists this information until you specifically clear the Console contents, as shown in Figure 1-3.

Figure 1-3. JavaScript console in Firefox

Firefox also provides what it calls the DOM Inspector. These very helpful utilities allow you to inspect the DOM objects within the page, including the following very useful information (the computed style is shown in Figure 1-4):

DOM Node

Node name, type, class, namespace URI, and value

Box Model

Position, x and y values

Computed style

The default styles for the object

XBL Binding

The Extensible Binding Language (not covered in this book)

CSS Style Rules

The CSS style rules that apply by default for an element and are given in the stylesheet

Figure 1-4. Computed style as shown in Firefox DOM Inspector

The JavaScript object, shown in Figure 1-5, is of particular importance because it provides a listing of events, properties, attributes, and functions accessible on the object from JavaScript.

Figure 1-5. JavaScript object from the DOM Inspector

In addition, there are any number of tools now—standalone or embedded—that can work with JavaScript. Rather than attempt to touch on a selection in one chapter, I include sidebars in several chapters that provide a brief overview of handy gadgets, libraries, and tools.