The Behavior Layer

By Peter-Paul Koch

published on January 14 2004

Now that Web developers have a solid grip on the XHTML structural and CSS presentation layers, it’s time to consider the JavaScript behavior layer and especially its accessibility.

In the past JavaScript has been much abused, mainly because people misunderstood its purpose. Many sites used JavaScript for presentation only, for instance in ubiquitous and ultimately boring DHTML interfaces.

The average DHTML site is not very accessible, to put it mildly, and the countless “revolutionary” interfaces turned out not to be very interesting or useful, except for highlighting the cleverness of their programmers.

This abuse has given JavaScript a bad name. It’s high time to reverse that trend. In my opinion JavaScript can form a valuable addition to an accessible Web site, as long as we take a few precautions.

In this column I’d like to take a look at the relationship between the JavaScript behavior layer and the structural and presentation layers. We’ll find a few simple, general rules that can help us keep a site accessible while allowing full scope to JavaScript’s power.

An example page

Let’s create an accessible, simple page for, say, an online bookstore. The page contains a bunch of links for navigation, an article about a book as the main content, and finally a short form for ordering the book.

All this content should be marked up as simply as possible. Headers and paragraphs contain the main article, hyperlinks and their container(s) form the navigation. The form consists of input fields and labels. We might add three overall <div>s, one to enclose the navigation, one to enclose the content, and one to enclose the form.

Then we add a bit of CSS presentation. We add margins and paddings to the various blocks, nice link colors and hover effects, and asubtle color shading for the form. Nothing revolutionary, just some nice styles to please the eye of the beholder.

Thinking in layers

It is important to recognize that we have now created two layers: a structural layer in XHTML, and a presentation layer in CSS. The XHTML layer is always present, without it we wouldn’t have a Web page. The CSS layer, however, may be absent.

In other words, we have defined two “views” of the same document: the presentation view where the CSS works, and the plain view where it doesn’t. At its most basic, accessibility is the art of making sure that the page still works when the CSS is absent, of making sure that the XHTML structure in itself is sufficient to understand and use the content and the navigation.

It is also important to recognize that the CSS view is more usable than the plain view. CSS is all about presentation. Good presentation, however, is a step towards better usability.

Any designer knows that a margin and some extra line height makes text easier to read, hence more usable. Besides, CSS could be used to distinguish between the main navigation links and other links in the body of the text, which also has small-but-obvious usability benefits.

All this is old news to anyone who’s following Web development literature. The structural and presentation layers are being heavily scrutinized, and we’re slowly creating a doctrine of efficient, accessible XHTML structuring and CSS presentation.

We have no such experience with JavaScript, though. We’ve hardly studied it in the context of accessible sites yet.

Adding JavaScript

JavaScript forms the behavior layer. If the user does something, JavaScript can make the page (or the whole site) behave in a certain way. The purpose of this behavior is to make the site more usable.

Our example page could use a form validation script. When written properly, such a script is a nice usability feature since it can gently inform the user of any mistakes he made while filling out the form, instead of requiring him to wait for a server response and then to go back to the form to correct errors. (If form validation scripts go bad, they go very bad indeed, but let’s assume ours doesn’t.)

We have now added a behavior layer to our simple page. It lies on top of the structural layer, and next to the presentation layer. This means that instead of two views we suddenly offer four. The plain view (XHTML only) and the simple presentation view (XHTML + CSS) remain as they were.

The behavior layer completes the full view (XHTML + CSS + JavaScript), and since we know that the vast majority of our visitors will actually use this view we spend lavish amounts of time and attention on it.

Accessibility alert: “vast majority” is not “all users”. Therefore we must make sure that our page continues to function without JavaScript. This simple but important rule is fortunately becoming common knowledge. If we validate our form server-side, too, we have satisfied this rule.

The fourth view

There is a second accessibility alert, though, one that tends to be overlooked. We find it as soon as we study the fourth view, the simple behavior view (XHTML + JavaScript).

Most Web developers vaguely assume that any browser that supports JavaScript also supports CSS. While this is true most of the time, there are a few browsers that support JavaScript but not CSS. Furthermore it is conceivable that an end user sets his own style sheet to override the Web site author’s CSS, creating his own presentation layer while using the author’s behavior layer.

If one of the few surviving Netscape 3 users visits our example page he gets the simple behavior view. Netscape 3 doesn’t support the slightest bit of CSS, but it can handle a form validation script.

Therefore our script should take this possibility into account. In other words, it should not rely only on style changes to inform the user of his mistakes. Just making the faulty inputs red and saying “Please re-enter the red fields” is not permitted.

Fortunately form validation scripts are older than Netscape 3, and most of them use alerts. Alerts aren’t the friendliest things that happen to users, but they work in all JavaScript browsers.

Besides, nowadays we have more sophisticated means to inform the user. We could put the error messages right next to the input fields in soothing, large, user-friendly letters. In that case, the script shows the alert only when the browser doesn’t support such high-end functionality.

Once we’ve written a script along these lines, making the faulty form fields red is quite allowed. Now the effect only serves to enhance the other warnings, and if it doesn’t work, nothing is lost. But the text of the error messages remains crucial. We can’t be sure that the user will see red fields, so using the words “red fields” anywhere is strictly forbidden.

Full view styles

One accessibility problem remains: the use of styles explicitly meant for the full view (XHTML + CSS + JavaScript).

Suppose our navigation gets larger and larger and we decide to create a script to make it more usable. Initially the navigation only shows the main categories. Clicking on or mousing over a category reveals the links it contains.

We have to hide the actual blocks of links by, for instance, display: none. The script toggles the display of the blocks between block and none.

This script works fine in the full view. It doesn’t work in the plain view (XHTML only) or in the simple behavior view (XHTML + JavaScript) because these views don’t support styles at all. That’s no problem as long as we structure our XHTML correctly. The user sees a long list of links with the category names as headings. The navigation is less usable but still accessible.

The problem lies in the simple presentation view (XHTML + CSS). If we’d just put display: none somewhere in the style sheet the browser would faithfully hide the blocks of links. If JavaScript doesn’t work, though, the user has no way of actually seeing and using the links. The navigation doesn’t work, therefore the site is inaccessible.

Fortunately the solution is simple: If you want to use styles that hide content and should later be overruled by a script, set these styles in JavaScript. Instead of adding display: none to our style sheet we should add an onload routine to our script that sets the display of all blocks of links to none. If the script doesn’t work the blocks aren’t hidden and the navigation remains accessible.

Using JavaScript responsibly

Let’s repeat our findings. First the point of JavaScript:

Any JavaScript should enhance the site’s usability. I feel that this point should be made repeatedly and forcefully during the next year. Too many people use scripts for the wow-factor only, and/or to prove their JavaScript mastery. If you’re not sure what your script is good for, don’t use it. This especially goes for complicated and pointless DHTML interfaces.

There are three general rules for the use of JavaScript in an accessible site.

The site should still work when the browser doesn’t support JavaScript, obviously.
The script should still work when the browser doesn’t support CSS. A script may not rely on style changes alone to achieve its purpose. Creating a behavior layer without assuming the existence of a presentation layer to back it up can be tricky. I feel we should pay more attention to this problem in the coming year.
Styles that hide content and are meant to be overruled by a script, should be set in JavaScript. If you add display: none to your CSS and rely on JavaScript to toggle it, your site will degrade fast when JavaScript is disabled but CSS is enabled.

When creating a JavaScript behavior layer you should pay careful attention to these three rules. Combined with some logical thinking, they’ll assure your site’s continuing accessibility even when you use very advanced JavaScripts.

Note, however, that “continuing accessibility” does not mean “perfect usability”. The site will be dramatically more usable in the full CSS/JavaScript view than in the plain view. That cannot be helped, and it shouldn’t stop us from creating useful JavaScript interfaces.

In a future column I’ll discuss this tricky and potentially dangerous “accessibility vs. usability” question in more detail.

Peter-Paul Koch is a freelance Web developer, writes and maintains www.quirksmode.org and is an Administrator of the WDF-DOM mailing list.