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.
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.
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 fourth view
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.
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
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
The problem lies in the simple presentation view (XHTML + CSS). If we’d just put
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.
- 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.
In a future column I’ll discuss this tricky and potentially dangerous “accessibility vs. usability” question in more detail.