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:
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.
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.
DOCTYPE
You will probably be familiar with the basic structure of an HTML document. Leaving out a great many details, it looks like this:
<html>
<head> </head>
<body> </body>
</html>
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"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
DOCTYPE.<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
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"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
DOCTYPE; choose this one if you also use frames.Some details must be mentioned, if only en passant.
DOCTYPEs are also available, but XHTML 1.1 is newer (dating from May 2001, halfway through the writing of this book), hence is used by fewer developers; 1.1, moreover, is stricter even than XHTML 1.0 Strict.DOCTYPE, which, for HTML documents written in Roman-alphabet languages, will typically be <?xml version="1.0" encoding="UTF-8"?>. The presence or absence of this declaration, which pertains to the encoding of characters used on that Web page, does not alter our discussion here, and in any event it is known to be incompatible even with very new browsers.DOCTYPE is technically optional for HTML documents and mandatory for XHTML documents; browsers may behave differently if you do or do not include it. This too does not alter our discussion here.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 (validator.w3.org). 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:
<html lang="en">
<html lang="en">
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>.
<p lang="de"></p>. A block quotation (<blockquote></blockquote>) can take a lang="languagecode" attribute as readily as anything else can, and might well be a better option if you’re excerpting a full paragraph.<span lang="fr"></span> or, if you want to be pluperfect, <cite lang="fr"></cite> (since you are actually citing the French terms).<div lang="languagecode"></div>. This <div></div> element can of course be nested within other <div></div> elements.
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.
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.
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.
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
- General
- Provide a text equivalent for every non-text element (e.g., via
alt,longdesc, or in element content). This includes: Images, graphical representations of text (including symbols), imagemap regions, animations (e.g., animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.- Ensure that all information conveyed with colour is also available without colour, for example from context or markup.
- Clearly identify changes in the natural language of a document’s text and any text equivalents (e.g., captions).
- Organize documents so they may be read without stylesheets. For example, when an HTML document is rendered without associated stylesheets, it must still be possible to read the document.
- Ensure that equivalents for dynamic content are updated when the dynamic content changes.
- Until user agents allow users to control flickering, avoid causing the screen to flicker.
- Use the clearest and simplest language appropriate for a site’s content.
- And if you use images and imagemaps:
- Provide redundant text links for each active region of a server-side imagemap.
- Provide client-side imagemaps instead of server-side imagemaps except where the regions cannot be defined with an available geometric shape.
- And if you use tables:
- For data tables, identify row and column headers.
- For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.
- And if you use frames: Title each frame to facilitate frame identification and navigation.
- And if you use applets and scripts: Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
- And if you use multimedia:
- Until user agents can automatically read aloud the text equivalent of a visual track, provide an [audio] description of the important information of the visual track of a multimedia presentation.
- For any time-based multimedia presentation (e.g., a movie or animation), synchronize equivalent alternatives (e.g., captions or [audio] descriptions of the visual track) with the presentation.
- And if all else fails: If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.
Priority 2 requirements for Level AA compliance
- General
- Ensure that foreground and background colour combinations provide sufficient contrast when viewed by someone having colour deficits or when viewed on a black and white screen.
- When an appropriate markup language exists, use markup rather than images to convey information.
- Create documents that validate to published formal grammars.
- Use stylesheets to control layout and presentation.
- Use relative rather than absolute units in markup language attribute values and stylesheet property values.
- Use header elements to convey document structure and use them according to specification.
- Mark up lists and list items properly.
- Mark up quotations. Do not use quotation markup for formatting effects such as [indention].
- Ensure that dynamic content is accessible or provide an alternative presentation or page.
- Until user agents allow users to control blinking, avoid causing content to blink (i.e., change presentation at a regular rate, such as turning on and off).
- Until user agents provide the ability to stop the refresh, do not create periodically auto-refreshing pages.
- Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.
- Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user.
- Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.
- Avoid deprecated features of W3C technologies.
- Divide large blocks of information into more manageable groups where natural and appropriate.
- Clearly identify the target of each link.
- Provide metadata to add semantic information to pages and sites.
- Provide information about the general layout of a site (e.g., a site map or table of contents).
- Use navigation mechanisms in a consistent manner.
- And if you use tables:
- Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).
- If a table is used for layout, do not use any structural markup for the purpose of visual formatting.
- And if you use frames: Describe the purpose of frames and how frames relate to each other if it is not obvious by frame titles alone.
- And if you use forms:
- Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.
- Associate labels explicitly with their controls.
- And if you use applets and scripts:
- For scripts and applets, ensure that event handlers are input device–independent.
- Until user agents allow users to freeze moving content, avoid movement in pages.
- Make programmatic elements such as scripts and applets directly accessible or compatible with assistive technologies.
- Ensure that any element that has its own interface can be operated in a device-independent manner.
- For scripts, specify logical event handlers rather than device-dependent event handlers.
Priority 3 requirements for Level AAA compliance
- General
- Specify the expansion of each abbreviation or acronym in a document where it first occurs.
- Identify the primary natural language of a document.
- Create a logical tab order through links, form controls, and objects.
- Provide keyboard shortcuts to important links (including those in client-side imagemaps), form controls, and groups of form controls.
- Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links.
- Provide information so that users may receive documents according to their preferences (e.g., language, content type, etc.)
- Provide navigation bars to highlight and give access to the navigation mechanism.
- Group related links, identify the group (for user agents), and, until user agents do so, provide a way to bypass the group.
- If search functions are provided, enable different types of searches for different skill levels and preferences.
- Place distinguishing information at the beginning of headings, paragraphs, lists, etc.
- Provide information about document collections (i.e., documents comprising multiple pages).
- Provide a means to skip over multi-line ASCII art.
- Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.
- Create a style of presentation that is consistent across pages.
- And if you use images and imagemaps: Until user agents render text equivalents for client-side imagemap links, provide redundant text links for each active region of a client-side imagemap.
- And if you use tables:
- Provide summaries for tables.
- Provide abbreviations for header labels.
- Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns.
- And if you use forms: Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas.
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 (cast.org/bobby/). In August 2002, Bobby was “acquired” by a firm called Watchfire (bobby.watchfire.com). 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, NewRiders.com, 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.
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.
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.
DOCTYPE on every single page and a language code on each html tag.