The structure of accessible pages

AUTHOR’S NOTE – You’re reading the HTML version of a chapter from the book Building Accessible Websites (ISBN 0-7357-1150-X). Copyright © Joe Clark, 2002 (about the author). All rights reserved. ¶ Back to Contents

Accessible Web authoring relies on standards. HTML accessibility tags are defined in standards (actually “recommendations”) issued by the World Wide Web Consortium (the W3C or W3). If you want the accessibility provisions of your pages to function predictably and reliably, you must work with the standards, not against them.

In other words, forget about coding special workarounds for Netscape 4. Forget marquee and other nonstandard HTML tags embraced and extended by Microsoft or “innovated” by Netscape. Forget anything that isn’t in the spec. Forget it all, even if your favourite browser relies on it.

“But-but-but!” you sputter. “I run a commercial Website with ten million hits a month. We do a browser sniff for Windows and Mac versions of Explorer and Netscape because we can’t get our standard design to look the same in all four. Are you saying I have to choose between what I’m doing now and accessibility?”

Um, yes.

Quite bluntly, none of us should be made to suffer for the longtime failure of browser makers to conform to W3C standards. (Really, I’m talking about Netscape, but Microsoft cannot play the angel here, either.) We all deserve better.

The decision by developers to code around the incompatibilities of existing browsers has had certain consequences, among them the fact that such incompatibility has to come to an end someday. If you want your pages to function with accessible coding, that day is today. You have enjoyed a lengthy crime spree, but I hear the handcuffs jingling.

There are now enough browsers available with reasonable standards compliance that real-world sites can finally get away with coding to those standards. It’s the only way to assure accessibility.


In this chapter:

Leave yesterday behind

What happens to Netscape 4 users? Pages won’t look so hot for them. Big deal. Absolute visual equivalence was always a pipe dream in any case.

Let’s recap the reality of the World Wide Web:

The sooner you grasp the reality that you are not designing for print, where you can oversee every single dot on a page, the sooner you will succeed as a Web designer, let alone as a contributor to an accessible Web.

If you’ve done any kind of reading on Web design or if you’ve simply looked at the same pages on different computers, you know that ironclad visual control is unattainable. Don’t cling to a myth, and don’t try to tell us your myths are real. No one’s ever seen a unicorn, either.

A question that comes to mind, of course, is “What about people stuck with Netscape 4? Aren’t they a disadvantaged minority who are rendered functionally disabled by their out-of-date equipment?” True enough, but the parallel with, say, a blind person using adaptive technology like a screen reader is not quite apt. Netscape 4 in particular will actively sabotage standards-compliant coding – everything from table cells to alt texts. Designers and developers do not bear sole responsibility for accessibility; the site visitor must come to the table with something resembling functional equipment. In that vein, when adaptive technology like a screen reader ignores or misinterprets fully legal HTML, site authors can quite reasonably consider themselves blameless; they too have come to the table with functional equipment in the form of standards-compliant HTML coding.

Nonetheless, it is true that people stuck using broken or outdated equipment like Netscape 4 (because, for example, it is the standard at the company they work for or the school they attend) genuinely are stuck. But that is not a problem designers and developers should be expected to solve. If anything, hewing to strict standards compliance acts as an inducement to get rid of outdated equipment.

Frankly, it causes less harm to sentence users of nonstandard equipment to nonstandard Web experiences than to hold back the adoption of standards that benefit everyone else, including the disabled. Standards-compliant devices behave in a more or less standard way. Other devices do not.

Now, it is in fact true that you can plop a few access tags (particularly those found in Basic accessibility as documented in this book) into a maelstrom of nonstandard HTML and be reasonably assured of a modicum of improved accessibility. But it’s not reliable (try reading title texts in Netscape 4), and it’s also too complex to maintain. Instead, I will teach you strictly legal, up-to-the-minute techniques using XHTML and cascading stylesheets. In some cases, incorrect or absent interpretation of access tags causes incompatibilities, but that tends to limit itself to the same outdated browsers I recommend you no longer coddle.

An example, mentioned in passing above, is the provision of graphic images’ alt texts as pop-up tooltips in version 4 of Netscape Navigator and Internet Explorer – a categorical, open-and-shut violation of W3C standards, which hold that alt is a replacement, not an addition (“Several non-textual elements... let authors specify alternate text to serve as content when the element cannot be rendered normally”). Yet if you provide alts anyway, these same misbehaving browsers work correctly when image-loading is deactivated and, moreover, alts work properly in every other browser, too.

What about “old” browsers like Lynx? Indeed, Lynx is the only example anyone ever cites, because there are very few text-only browsers in the world today and Lynx is the giant squid flailing about in a very small pond. (Other text-only or “console” browsers are WannaBe, Links, and W3M.) Ironically, these programs do a very admirable job of interpreting standard HTML. (Working under severe limitations can force higher quality.) An accessible HTML page remains accessible for these browsers.

Basic page structure

You have to abide by only a few ironclad rules in structuring HTML pages. They’re dead-simple. You can save them in templates in your authoring program, or set up your own stationery, or simply drag and drop the codes. Let’s cover a couple of features you must use to assure accessibility.

Start off with DOCTYPE

You will probably be familiar with the basic structure of an HTML document. Leaving out a great many details, it looks like this:

<head> </head>
<body> </body>

But a certain code goes in front of all that, the DOCTYPE. This document-type declaration informs the browser or device what kind of page it’s dealing with. It sits at the very top of an HTML file, before anything else (and with no carriage returns or spaces preceding it).

While there are a range of DOCTYPEs available for different levels of HTML (that is, HTML 4 as distinct from XHTML), the options for XHTML 1.0 DOCTYPEs you are most likely to use are as follows:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
XHTML 1.0 Strict – If you’re super-hardcore and write XHTML that includes no elements tolerated from the olden days whatsoever, use this DOCTYPE.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
XHTML 1.0 Transitional – You’ll be using this DOCTYPE most of the time. It permits certain old-fashioned “presentational” elements, as explained below.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
XHTML 1.0 Frameset – Identical in effect to the Transitional DOCTYPE; choose this one if you also use frames.

Some details must be mentioned, if only en passant.

What does it all mean?

Let’s start with a quick history lesson. While HTML has been tarted up considerably since its earliest days, its fundamental purpose is to mark up the structure of a document, not its appearance. “Presentational” elements, like B for bold, have been discouraged but tolerated. (Everyone has a presentational element they love to hate. blink and marquee – the element that makes text march across the screen like a cavalcade of ants – are infamous villains. I personally cannot stand u. We invented italics for a reason, and underlining has special purposes online. Indeed, later I’ll show you some accessibility applications for underlining.)

Meanwhile, “structural” elements (like <strong></strong>, whose contents may indeed be displayed using bold type) are the preferred approach. Accessibility elements are structural, to a greater or lesser degree, though as elsewhere in HTML discourse, “structural” is as porous a concept as “presentational.”

Getting back to DOCTYPE: Someday all browsers and devices will read the DOCTYPE and vary their interpretation of the subsequent code. At time of writing, only Mozilla (hence also Netscape 6 and 7), Internet Explorer for Macintosh version 5 and later, and Windows IE 6 perform this so-called DOCTYPE-switching, but it provides an augury of the future.

If your document uses a Strict DOCTYPE (any Strict declaration at all – older HTML 4-level DOCTYPEs work fine), then, for example, Explorer 5 for Macintosh interprets HTML and stylesheets with commensurate strictness. One example from Tantek Çelik, a leading Microsoft browser developer: “Strict interpretation causes a strict treatment of the [Cascading Stylesheets] box model, whereas non-strict interpretation causes a backward-compatible (i.e., Windows IE 4–compatible) interpretation.” Another example from Çelik: Unitless dimensions, which are “rejected in Strict mode as illegal values – with the exception of line-height, which specifically allows a unitless value [with] a particular meaning.”

It is not improper to use a Transitional declaration. In certain cases, you may require Strict-level control over stylesheets, but it’s generally unnecessary, and nothing says that all the pages within your site have to use the same DOCTYPE. You can mix and match as appropriate.

There is another reason to declare your document type: You must do so in order to prove your document is correct or valid HTML. To validate a document means to check it for errors, and, at time of writing, there is only one official validator, located at the W3C’s own Website ( Since there are so many variants of HTML and XHTML, the validator, which is nothing more than a software program, must be told up front which reference standard to use. The DOCYTPE does exactly that. If you want to write pages that are true, valid HTML, you must use a DOCTYPE or your page won’t validate.


While this may contradict whatever passes for conventional wisdom in the accessibility demimonde, making your site work in some other language really does constitute accessibility. (When you visit a Website, you can’t change the languages you understand, can you? Aren’t you functionally disabled if the site you want is in Dutch and you don’t read a word of it?)

I’ve elected to keep this book focused on disability-related accessibility, but there’s one language detail you cannot ignore. It is a ramification of an accessibility requirement that forces you to declare a change in natural language in your document.

What’s a natural language? It’s a human language, as distinct from a computer language like C++, Pascal, or PostScript. Natural languages are not necessarily spoken; indeed, essentially all the language available on Websites is written, though sign languages are also natural languages.

Why do you have to declare a change of language? Because adaptive technology can theoretically alter its interpretation of a document – by switching Braille standards or using a new voice dictionary, for example. If you specify that a passage in your document is actually written in French, a screen reader able to interpret and enunciate French won’t attempt to read the text as fractured English.

There’s an implication here that you must respect. To mark a change in language, the original language must have been specified. Otherwise what are you changing from?

Just add a language attribute to the html tag in the head element. Whatever else ends up in your <html></html> element, add lang="en", as in these examples:

As elsewhere in HTML, order of attributes in a tag does not matter. There is a wrinkle: In one of the very few differences between XHTML 1.0 and 1.1, if you wish to use the latter you must write xml:lang="languagecode" in all tags where you would once have used lang="languagecode". It is not wrong to use both in XHTML documents, but it is wrong in HTML 4.

The en code, as you have probably gleaned, means English. You are under no obligation to write Web pages in English. You may produce French or Icelandic or Spanish pages in your day-to-day work, or for special localization projects. All you need to do is match the language you’re using with the appropriate language code, a full listing of which is given in Appendix B, “Language codes.” Use whatever code applies to the language a visitor will encounter and read. Possible sources of confusion:

Now, the actual requirement in the Web Content Accessibility Guidelines states: “Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions).” To do so, merely add lang="languagecode" or xml:lang="languagecode" to whatever tag structurally encloses the foreign-language text. Typically, you will use <p></p>, <div></div>, <blockquote></blockquote>, and <span></span>.

Do not use this technique to indicate foreign-language proper names save for extremely rare cases. A man named Simon Robert who is in fact Swiss and not British may wish to mark his name as <span lang="fr-ch">Simon Robert</span> in the hopes (possibly vain) of triggering a French pronunciation in a screen reader. But these cases are rather quite unlikely to come up in day-to-day Web design.

There is no convention for the use of language codes to indicate the language of multimedia. Technically, you can add lang="languagecode" to an enormous range of HTML elements; it is possible, therefore, to add lang="languagecode" to, say, the object but not the embed element (both of which are discussed in greater length in Chapter 13, “Multimedia”).

If your page includes a link that opens a new document that in turn contains the multimedia file, you may use the hreflang="languagecode" attribute on the <a></a> element to indicate the language of the destination.

And if you think those are complex, elusive, and rarefied examples, they are.

Quickie review

Set up templates for all future documents to include a DOCTYPE and a language attribute on the <html></html> element.

There. That was the easy part.

The Web Content Accessibility Guidelines

In exploring Web accessibility, one quickly learns that all roads lead to the WAI, the Web Accessibility Initiative of the World Wide Web Consortium.

The WAI, founded in 1997 and headed, at time of writing, by Judy Brewer, describes its purpose as follows: “The World Wide Web Consortium’s... commitment to lead the Web to its full potential includes promoting a high degree of usability for people with disabilities. WAI, in coordination with organizations around the world, pursues accessibility of the Web through five primary areas of work: Technology, guidelines, tools, education and outreach, and research and development.”

Everyone working in Web accessibility swims in a pool filled a bucket at a time by the WAI. The entire base of widespread understanding, knowledge, and scholarship on Web access can be traced to the WAI, including this book, which nonetheless diverges from the gospel in limited ways.

In your role as a Web designer or developer, your interest will focus on the WAI’s Web Content Accessibility Guidelines (WCAG), which explain how to write HTML and other authoring languages accessibly.

If you’ve ever tried to actually read and comprehend the WCAG, I can understand why you ended up buying this book. Reading a dictionary from back to front is a more pleasant experience than plodding through pretty much any document the WAI has ever produced, including the WCAG.

The guidelines are too vague and too detailed all at once; ask for the moon, without giving you a rocket to get you there or even instructions on how to build one; and are unusably long and meandering.

Worse, the WCAG are written with no discernible authorial voice – no doubt under the guise of “objectivity,” but leaving the impression that the words were strung together by a committee of Brussels functionaries.

The Web Content Accessibility Guidelines, then, while constituting the gospel of whatever endeavour that Web accessibility hopes or pretends to be, are unworkable in practice.

Yet you – and I – are forced to become fluent in the guidelines nonetheless. They represent our environment.

The best I can hope for is that this book becomes a kind of companion volume, like an interpretation of the gospel. You can and will consult the inscrutable source text from time to time, but I hope you will learn more in these pages.

1, 2, 3; A, AA, AAA

This book teaches a phased approach to accessibility, with Basic, Intermediate, and Advanced steps applicable to most tasks in Web design and programming.

On the surface, the WCAG take the same approach, offering three priority levels in Web content accessibility. Priority 1 techniques are the highest; authors “must” do them. You “should” use Priority 2 techniques and “may” use Priority 3s.

Having already given us a three-tier classification system, the WAI proceeds to give us another one: Level A, AA, and AAA compliance. If your site meets the requirements of a particular accessibility level by fulfilling all requirements for Priority 1, 2, or 3, you have the right to mark your site as meeting a corresponding level of access. From the actual guidelines:

As it turns out, Basic access as described in this book usually corresponds to Level A, and Intermediate and Advanced access to Levels AA and AAA, respectively, but the correspondence is not exactly one-to-one. In particular, the WCAG’s expectations for multimedia access are unrealistic for all but the very largest Web conglomerates, and even for those entities the cost escalates quickly.

At times, this book explicitly counsels you to defy the Web Content Accessibility Guidelines, but only with very good reason and under strictly limited circumstances. In other words, I give you a defence, which might disappear if circumstances change (e.g., your budget increases or access technology improves).

In order to demonstrate the confusion and complexity that typify our environment, let’s look at the checklists for Priority 1, 2, and 3 accessibility. In the W3C’s grand tradition, the document from which these items are adapted is entitled “Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0.” A checklist of checkpoints? How is that different from a checklist? (Isn’t that like saying your wall is covered by a bookshelf of books of pages of words?)

I’m giving these “checkpoints” to you up front, before any concepts are explained, to give you an idea of the lay of the landscape. What follows is the level of explication everyone working in this environment has had to put up with.

Priority 1 requirements for Level A compliance

Priority 2 requirements for Level AA compliance

Priority 3 requirements for Level AAA compliance

As you can see, a range of topics, some of them only tangentially related, are grouped within each level. True enough, the checkpoints provide links to further explanations of what is demanded of you, but you should not expect to actually understand all the descriptions and effortlessly put them into effect.

Level A/AA/AAA compliance is something you’ll have to wrap your mind around, and in certain cases (e.g., U.S. government agencies), you will, on paper, be required to certify such compliance exactly as prescribed in the guidelines. You may find that impossible to do. Just as some buildings and vehicles can never be made wheelchair-accessible without unreasonable and extraordinary measures, some features of Websites will remain inaccessible without similarly unreasonable and extraordinary measures. This does not constitute a blanket exemption; circumstances can change, and you are still required to do everything else in your program of improving accessibility. But the Web Content Accessibility Guidelines make few allowances for circumstances, let alone changing circumstances.

Here in the real world, you may simply live with failure to meet certain specific and highly-qualified details of the letter of the WAI’s unrealistic and overblown standards. That says nothing about the real-world accessibility of your site.

Nonetheless, this book builds up your understanding of concepts and techniques in its own way. Though I do not cover every detail, at the end of the process, you’ll be able to look at the Priority 1 through 3 and Level A through AAA requirements and, in most cases, know immediately what to do to meet them. You will also know when and under what circumstances you will not meet the requirements.

You will know enough at that point to be able to make sense of the mishmash of topics found in the compliance guidelines.


I devote an entire chapter (14, “Certification and testing”) to certifying accessibility. It’s not cut-and-dried. And that is the problem.

In evaluating accessibility in the physical world (in “meatspace”), a specification may call for a doorway 100 centimetres wide for wheelchair access. Your tape measure will tell in an instant if you comply or not. It may be somewhat involved to widen the doorway if it’s too narrow, and it may be impossible in rare cases, but the plan of action is predictable and reproducible.

Yet in cyberspace, every Website is slightly different. It’s possible to meet the letter of a requirement without meeting the spirit. For example, using the filename for an alt text on an image is technically legal, since you have in fact provided an alt, but the function of the alternative text is thwarted. (If you couldn’t see or use graphic images, is a replacement like spacer.GIF of any use to you whatsoever? Especially if you’re using a screen reader and have to listen to the words “spacer dot gee eye eff” over and over again?)

More pressingly, accessibility requires design decisions. The Web Content Accessibility Guidelines force such decisions, as does practical work on actual Websites. To reconsider the previous example, you may code an appropriate alt, but if you leave off titles and longdescriptions (documented in Chapter 6, “The image problem”), do you jeopardize your accessibility certification?

If you use the most minimal coding for HTML tables with no access tags or attributes, are you engaged in wrongdoing? If you provide a small text-only variant for an extravagant Flash animation, have you merely met the letter of the law and not the spirit?

In all these cases, the answer is “Quite possibly yes.” In building accessible Websites, you will be forced to make design decisions with no objective proof that your choices are defensible. But the whole point of the exercise is that objective proof is occasionally unattainable and unrealistic. And in general, such issues as these come up only in advanced cases. With this book as your guide and with a little practice, you will be able to make the right kind of defence of your accessibility choices – a combined functional and æsthetic defence.


A little knowledge is dangerous, and that maxim comes into play in two ways online.

Ever heard of Bobby? It’s a free online accessibility validator offered by CAST, the Center for Applied Special Technology ( In August 2002, Bobby was “acquired” by a firm called Watchfire ( Run your site through Bobby and it lists your accessibility failings (anything that violates Priority 1).

What is the problem, exactly? Well, there are two.

Easy example? Running an early version of the New Riders Website,, through the Bobby validator elicited a sequence of clear-cut Priority 1 errors (all pertaining to alt texts, easily cleaned up) and a litany of errors that more or less mean “I can’t tell what you were really doing or if you’ve actually made a mistake, but here’s an error message just in case”:

Then Bobby simply nags at you:

What we have here is a computer program that threatens to withhold its certification badge (of dubious value in any case) if you didn’t write clearly enough. How does it know the difference, exactly? You probably get enough of that kind of bellyaching at home. Do you also need it at work?

My advice is simple: Do not use Bobby. Do not rely on software as dumb as a dromedary to evaluate accessibility.

An environment desperate for an upgrade

You now know how muddled the “environment” in which we work actually is. Starting now, you and I are going to hack out a kind of quality upgrade for Web accessibility.

Separate pages are not equal

Let’s put a myth to rest right here and now. There is no real benefit to setting up – either manually or through a content-management system that autogenerates pages on demand – a regular page and a so-called “accessible” page. Here, “accessible” usually means “text-only.”

Now, this is not the same as self-reconfiguring pages that respond to the visitor’s preferences, as described in Chapter 15, “Future dreams.” Nor does it really have anything to do with separate printable pages (which very often are functionally equivalent to text-only pages), which in any case can be generated by a media="print" stylesheet and nothing more.

Separate “accessible” pages are wrong in principle because they cause segregation. You’ve got your back-of-the-bus page for those disabled people and your regular page up front for the real people. Nearly any Website imaginable can be made accessible enough within itself that an allegedly superior separate page isn’t necessary.

And anyway, a text-only page simply does not carry the same information as a regular page. Graphics, typography, colour schemes, and page design are information. Moreover, not every person with a disability benefits from a text-only page, a case in point being learning-disabled people who get bogged down in masses of continuous text.

And do untrained but well-intentioned designers out there really have any idea what an “accessible” page would be other than a text-only page? What does it really mean? Answer: Nothing.

The bottom line is that separate is not equal.

Bottom-Line Accessibility Advice

Basic, Intermediate, and Advanced

Previous   ¶   Contents   ¶   Next