A List Apart


How to Save Web Accessibility from Itself

As is now quite widely known among indie developers and virtually unknown everywhere else, websites are properly created in accordance with published accessibility standards. The chief source for those standards is the set of “recommendations” by the World Wide Web Consortium’s Web Accessibility Initiative (the W3C WAI). These Web Content Accessibility Guidelines (WCAG 1.0) were last officially updated in 1999.

Article Continues Below

A new revision of the guidelines, WCAG 2.0, is being written. The development process is going slowly and is in danger of recapitulating many of the errors of WCAG 1.0 — unrealistic guidelines divorced from real-world web development that are at once too vague and too specific.

But you, the indie developer, can help prevent this tragedy by investing a small period of time in one of a few limited areas that may interest you. Instead of working on the entire WCAG, we need you to focus on topics in which you may have expertise or experience. By participating in this limited way, you can help save web accessibility from itself.

Enlightened self-interest

If you choose to make standards-compliant websites, inevitably you will have to follow the guidelines. It’s foreseeable that you could be legally required to follow WCAG 2.0. You could opt into following the guidelines or they could be foisted upon you.

You thus have an enlightened self-interest in ensuring the new guidelines actually make sense. Moreover, we simply need more contributors.

The participation problem

I’ve been posting to the W3C’s accessibility-related mailing lists since 1999 and I still haven’t figured out how the WAI works. You don’t need to, either.

You just need to know that the two main mailing lists for WAI discussions are:

WAI Interest Group. General discussion of web accessibility.
WAI Guidelines, home of the Web Content Accessibility Guidelines Working Group. Discussion of current and future guidelines.

Not surprisingly, more people are interested in WAI-IG’s general chitchat than WAI-GL’s topic-specific discussions. From June 2002 to June 2003, 290 different people posted to WAI-IG, but fewer than half as many (114) posted to WAI-GL.

That sounds like a lot,  but it isn’t. Web development now ranges widely, with many overlapping fields of expertise. WCAG 2.0 will impinge on many of those fields, including page structure (XHTML and similar markup languages), CSS, multimedia, usability, information architecture, writing, and myriad disability-specific issues. I know for a fact that leading experts in several web topics unrelated to disability, whose names would be immediately recognized by au courant indie developers, simply do not post to either mailing list. We have no evidence that actual experts in many pertinent fields are part of the development process for WCAG 2.0.

And it shows. The current drafts of WCAG 2.0 are a marked and indisputable improvement over the antediluvian WCAG 1.0, but they still have far too little bearing on the real world of the web.

This is where you come in.

Bite-size pieces

At press time, the current draft of WCAG 2.0 was 14,000 words long without markup. I don’t see how anybody could tackle something that big in one sitting. It’s like an anaconda trying to swallow a Range Rover.

What I’ve done, then, is to break up the WCAG draft into “action items,” as the business types say. The themes I have chosen are:

  1. Rewrite: The guideline needs rewriting and clarification
  2. Examples: The guideline requires many more examples, preferably drawn from actual websites (anonymized if necessary)
  3. Unclear on the concept: There’s something wrong with the basic idea of the guideline
  4. Impossible: The guideline, as written, is impossible to meet or virtually so
  5. Not our problem: The issue cannot reasonably be solved through guidelines governing web content

Deficiency report

Before everyone starts accusing me of being “too critical,” which is like accusing the sky of being too blue, understand that this article is a deficiency report on WCAG 2.0. We can’t afford to pretend to be more positive, upbeat, and complimentary than is justified by the actual guidelines. We have only a short window of opportunity to fix what’s wrong, and we can’t do that without identifying what’s wrong. This is no time to accentuate the positive.


(I have separately written two briefing documents for a previous face-to-face WCAG meeting that list deficiencies and recommendations, if anyone is interested.)

Where to find the originals

WCAG 2.0 is a moving target.

The documents don’t use enough fragment identifiers. You can’t link directly to enough sections and paragraphs. Where there’s a link, I’ll give it, but a lot of the time you’re going to be stuck using the Find command in your browser. Moreover, in subsequent drafts, wording is guaranteed to change.

Action items


These guidelines need rewriting and clarification. But the problem is much worse than that: The entirety of WCAG 2.0 is a poorly-written morass. The document violates its own draft guidelines on clear and simple writing. It is an outright mess, and urgent plain-English rewrites are required. The Web Accessibility Initiative, which has a budget, should hire professional plain-English consultants for this task. It’s time to end the W3C’s tradition of incomprehensible documents.

Still, for the purposes of this section, we’ll focus on sections that make next to no sense as written.

  1. Overview of Design Principles: Here, the four themes or “goals” of WCAG 2.0 are somewhat clumsily named as adjectives.


    • Perceivable
    • Operable
    • Understandable
    • Robust
  2. Make content perceivable by any user. The checkpoint needs fixing. Could you implement it as written?

    All non-text content that can be expressed in words has a text equivalent of the function or information that the non-text content was intended to convey.

    1. Non-text content that can be expressed in words has a text equivalent explicitly associated with it.

    2. Non-text content that cannot be expressed in words has a descriptive label provided as its text equivalent.

    3. The text equivalent should fulfill the same function as the author intended for the non-text content (i.e., it presents all of the intended information and/or achieves the same function of the non-text content).

  3. What is “non-text content”?


  4. WAI’s warning against the use of illustrations: If this guideline even deserves to be included, it requires rewording.


  5. Retransmitted captioning and audio description: Can you understand this guideline?

    If content is rebroadcast from another medium or resource that complies to broadcast requirements for accessibility (independent of these guidelines), the rebroadcast satisfies the checkpoint if it complies with the other guidelines.

  6. Definitions should be definitive. These aren’t.


      Content is the information or meaning and function.  






In this section, these guidelines require more examples. Here is where my readers can do the most good with the least effort: All we need, in most of these sections, are a few people’s contributions of one or two examples each of real-world sites. The sites you suggest could fully meet, partially meet, or entirely fail the proposed guideline.

You can also recount your own lived experiences as a web user.

The important thing here is to get WAI out of its habit of half-arsed hypothesizing. We want their guidelines applied against existing sites of all descriptions. WAI is not interested in finding those sites on its own, so we have to hand the facts to them on a platter.

  1. Yet more text equivalents. WAI just can’t get enough of those. But we need a wider range of actual examples of text equivalents in real use today, whether well-done or not.




  2. WAI dabbles dangerously in the issue of writing, a topic about which it has a demonstrable lack of expertise. Its concern with “concrete concepts” and similar classifications of the written word is meant to assist people with learning disabilities, but little good will come of it unless we know exactly what they’re talking about. Do you?

    • Example 1: A description of a process.


    • Example 2: A concrete concept.


    • Example 3: Child’s report of school trip.  

      A child went with her school on a trip to a bicycle manufacturing plant. She wrote a report for her family and friends to post to the web. In the report, she includes the company logo as well as a picture of a bicycle on the assembly line. She links to the company website for more information. She includes photos she took of the plant.

    • Example 4: Stock-trading data.

      A news site is comparing the performance of the economy from third quarter of this year with third quarter from the last three years. They compare prices of the most popular stocks. They present the data in a bar graph with a link to the raw data they used to create the bar graph.

    • Example 5: History of music.

      A grandfather’s hobby is listening to and playing music. He creates a website that includes examples of many different types of music and musical instruments. When describing specific types of music, he links to a short sound clip.

  3. Benefits of accessible alternatives need a few case studies (which, oddly, WAI could crib from its own page).


    • Individuals who are deaf, are hard of hearing or who are having trouble understanding the audio information for any reason can read the text presentation or have it translated and presented as sign language by their assistive technology.

    • Individuals who are blind or deaf-blind can have the information presented in Braille.

  4. Examples of multimedia accessibility: I know I’m not the only one who actually watches captioning and audio description. I know that few involved in WAI do. Real-life experiences and examples are called for here.

    • Example 1: A movie clip with audio description and captions.

      A clip from a movie is published on a website. In the clip, a child is trying to lure a puppy to the child’s bedroom by laying a trail of crumbs. The child mumbles inaudibly to himself as he lays the trail. When not watching the video, it is not obvious that he is laying a trail of crumbs since all you hear is the mumbling. The audio description that is interspersed with the child’s mumbling says “Charlie lays a crumb on each stair leading to his room.” The caption that appears as he mumbles is [inaudible mumbling].

    • Example 2: A video clip of a news story.

      A video clip accompanies a news story about the recent flooding in a major city. The reporter describes what is seen, for everyone. No audio description is necessary. The captions display what the reporter is saying.

    • Example 3: A silent animation.

      An animation shows a pantomime climbing a ladder. There is no audio track for this animation. No captions or audio description are required. Instead, a text equivalent is provided….

  5. Surely we can come up with better real-world examples of a second language embedded in a paragraph. I also cleaned up WAI’s copy errors below.


    In the following sentence, “And with a certain je ne sais quoi, she entered both the room, and his life, forever,” the French phrase je ne sais quoi is marked as French. Depending on the markup language, English may either be marked as the language for the entire document except where specified, or marked at the paragraph level.

  6. The WAI is unaware that correct table markup makes table structure crystal-clear. Also, exactly what “semantic markup” could make, for example, homonyms, homographs, and figures of speech understandable?

    Provide a summary for relationships that may not be obvious from analyzing the structure of a table but that may be apparent in a visual rendering of the table.

    If contracted forms of words are used such that they are ambiguous, provide semantic markup to make words unique and interpretable.

  7. Here is where standardistas shine. We’re obsessed with the proper use of lists, headings, and other XHTML elements. Time to give WAI a taste of our glorious compliant medicine. We may have a problem finding examples of “chapters” and “sections,” because, although they are defined as “relationships” of the link element, there are no HTML elements for chapters or sections.

    (This passage of the WCAG is particularly pathetic, resorting to citing the structure of a bicycle to explain web structure.)

    1. The content has been reviewed, taking into account the following strategies for facilitating orientation and movement, applying them as appropriate.

      1. Breaking up text into logical paragraphs

      2. Providing hierarchical sections and titles, particularly for longer documents

      3. Revealing important non-hierarchical relationships, such as cross-references, or the correspondence between header and data cells in a table, so that they are represented unambiguously in the markup or data model

      4. Dividing very large works into sections and or chapters with logical labels

      5. Others?

  8. How many “expanding outlines” and “dynamic fisheye views” have you run through the W3C validator lately?

    site navigation mechanism



    • Site map(s)

    • Search engine(s)

    • Expanding outline(s)

    • Dynamic fisheye views showing all linked pages or topics related to any page.

    • 3D virtual representations of site content

  9. Better examples of consistent site layout, anyone?

    • The content has been reviewed, taking into account the additional ideas listed below:

      1. Place navigation bars in a consistent location whenever possible

      2. Similar layout for user interface components should be used for sections or whole site

      3. Similar user interface components should be labeled with similar terminology

      4. Use headers consistently

      5. Use templates for consistent presentation of sections or whole site

      6. Pages with similar function should have similar appearance and layout

      7. Controls that look or sound the same should be designed to act the same

      8. Conventions likely to be familiar to the user should be followed

      9. Unusual user interface features or behaviors that are likely to confuse the first-time user should be described to the user before they are encountered

  10. Popup windows and frames  are among the recurring W3C bugbears that are hardly ever used. Still, surely we can find better case histories than these.

    • Example 1: A form to deactivate pop-up windows.


    • Example 2: A warning given before a pop-up window.

      At the end of a news story, several links are provided for more information. At the beginning of each link is an icon of an arrow with the text equivalent, “Link will open in new window.”

    • Example 3: Frames that do not track history making the back button behave unexpectedly.

    •   Example 4: Forms.

    Editorial Note: Some of these examples are very brief. Should they be expanded and clarified with further details?

Unclear on the concept

These guidelines show such a deep misunderstanding of the topic they pretend to tackle that they should be deleted or massively rewritten. Where you can help: See if you can figure out what they are intended to mean and rewrite them. Or suggest reasons, preferably backed up with references to real-world sites and development practices, why they should be deleted.

  1. Unicode encoding is desirable, but it is not the only encoding available, nor does its absence impair accessibility.

    Text in the content is provided in Unicode or sufficient information is provided so that it can be automatically mapped back to Unicode.

  2. This guideline concerns captioning of web multimedia. Its plain reading requires a transcript of all real-time audio broadcasts. That is, every single Internet radio station would require transcription.

    Meanwhile, if you have any kind of webcam at all, you need to scrounge up some other site you can link to that is somehow the “equivalent” of the webcam’s image.

    If the web content is real-time and audio-only and not time-sensitive and not interactive a transcript or other non-audio equivalent is sufficient. [...]

    If the web content is real-time non-interactive video (e.g., a webcam of ambient conditions), either provide an equivalent… (e.g., an ongoing update of weather conditions) or link to an equivalent… (e.g., a link to a weather website).

  3. The Web Accessibility Initiative misunderstands the use of cascading stylesheets. Here it requires you to come up with a different appearance for dozens of HTML elements. (Should the elements em, cite, and i really look different?) It also requires you to code special black-and-white and monaural stylesheets.

    The structural elements present have a different visual appearance or auditory characteristic from each other and from body text. [...]

    The structural emphases are chosen to be distinct on different major visual display types (e.g. black and white, small display, mono audio playback). [...]

    1. For visual presentations, use font variations, styles, size and white space to emphasize structure.

    2. Use color and graphics to emphasize structure.

    3. For auditory presentations, use different voice characteristics and/sounds for major headings, sections and other structural elements.

    4. If content is targeted for a specific user group and the presentation of the structured content is not salient enough to meet the needs of your audience, use additional graphics, colors, sounds, and other aspects of presentation to emphasize the structure.

  4. Foreground/background distinctions are, as they say, a personal thing. WAI has provided no evidence that authors can reasonably anticipate how a person with a visual impairment or learning disability will be confused by figure–ground combinations. Further, who runs in “256 grayscale” anymore, let alone black and white (i.e., one-bit colour, like the original Macintosh)?

    1. When text content is presented over a background image or pattern, the text is easily readable when the page is viewed in 256 grayscale.

    2. Text content is not presented over a background image or pattern or the text is easily readable when the page is viewed in black and white (no grayscale).

    3. Audio content does not contain background sounds or the background sounds are at least 20 db lower than the foreground audio content.

    4. Text content is not presented over a background image or color or the colors used for the text and background or background image pass the following test:

      • No tests/algorithms are available at this time

  5. WAI has not recognized that many, or even most, web-based games are going to be inaccessible to someone. It doesn’t make a lot of sense to warn of an unpredictable response, thus making it predictable.

    Where inconsistent or unpredictable responses are essential to the function of the content (e.g. mystery games, adventure games, tests, etc.) the user is warned in advance of encountering them.

  6. Here is the single biggest minefield in which the Web Accessibility Initiative finds itself: Writing guidelines for learning-disabled people, who, the WAI is unable to acknowledge, may never be significantly accommodated online.

    The current drafts are a huge improvement over earlier suggestions, but WAI still clings to the notion that “content” can be “reviewed” to demonstrate that it is as simply written as possible. But write too simply and you may alienate your target audience. Here accessibility turns from making sites accessible to rewriting your own work — and making you illustrate it.

    Content is written to be no more complex than is necessary and/or supplement[ed] with simpler forms of the content.

    • the content has been reviewed, taking into account the following strategies for evaluating the complexity of the content, applying them as appropriate.

      1. Familiarity of terms and language structure

      2. Reasonableness of length and complexity of sentences

      3. Coherence of paragraphs (and sensibility in length)

      4. Clarity of headings and linked text when read out of context

      5. Accuracy and uniqueness of page titles

      6. Care in the use of all-capital letters where normal sentence case might increase comprehension

      7. Inclusion of non-text content to supplement text for key pages or sections of the site where they felt it was appropriate.

  7. Backward compatibility. There’s only so far back we can go in a world where nearly everyone uses a Version 5–or-later browser and authors are writing valid HTML and CSS, which are themselves supposed to be compatible across browsers and devices.

    As ever, there’s much discussion of people with outdated technology, which is an accessibility issue in a sense other than those within WAI’s purview. Everybody else has to upgrade; why are people with disabilities exempt? Should standards-compliant progress on the web be hindered because someone somewhere might be using an old screen reader?

    Nor is there any understanding of the new and more valuable concept of progressive enhancement — using baseline HTML and CSS to be compatible with any compliant device, but adding features that more-sophisticated devices can use.

    Benefits of determining and documenting baseline user agent requirements:

    • Individuals can identify (either through site documentation or automatically through metadata) whether or not they are likely to be able to use a site. In conjunction with a search engine or a proxy server, this could be used to automatically filter out sites a user cannot access or to automatically filter to the top sites that would be most usable.

    • Requiring sites to document their baseline will cause them to evaluate assumptions about user agents and will minimize the number of sites that are inadvertently inaccessible because they are unaware of backward compatibility issues.

    Benefits of designing for backward compatibility:



Next to impossible

The Web Accessibility Initiative publishes the following draft guidelines even though they are actually or nearly impossible to implement. Here we need you to provide technical explanations, which WAI members should have been able to come up with themselves but have not. Or you could nominate examples from the real world and explore how difficult it would be to apply the guidelines to them.

  1. “Collating” a “script” of audio descriptions and captions has been done exactly once in recorded memory — for a demonstration project that is not documented online. It is impossible in practice due to the lack of interchange formats for captioning, audio description, and related fields. Nor are there that many examples of multimedia that are captioned and described. It’s even rare, when you consider the full range of TV programs and movies, to find both captioning and description in those well-established fields.

    Live captioning is extraordinarily difficult for online media (nearly impossible using standards-compliant code), while live description has been attempted a mere five times in the broadcast sphere. Meanwhile, of course captions require you to read and watch at the same time. This isn’t telepathy.

    1. a text document that merges all audio descriptions and captions into a collated script (that provides dialog, important sounds and important visual information in a single text document) is provided.

    2. captions and audio descriptions are provided for all live broadcasts which provide the same information.

    3. the presentation does not require the user to read captions and the visual presentation simultaneously in order to understand the content.

  2. It’s impossible to write a stylesheet that detects the size and colour capabilities of a display and serves different commands as a result. Almost nobody uses black-and-white displays; audio stylesheets are effectively unsupported, and stereo audio is the norm. The guideline also apparently requires stylesheet-switchers on each and every site. The concept of “vary[ing] the emphasis of the structure” is rather hard to understand, unless it means making certain elements invisible or yet other elements render in 96-point type.


    2. Content is constructed such that users can control the presentation of the structural elements.

    3. Alternate presentation formats are available to vary the emphasis of the structure.

  3. This guideline, intended to help dyslexics and others with related learning disabilities, presupposes a Windows-style combo box (drop-down list plus type-in field). It would also require you to spell-check every input ever made on your website. That would seem to be the visitor’s responsibility, and it’s already possible.

    1. Where possible, the user is allowed to select from a list of options as well as to generate input text directly.

    2. Errors are identified specifically and suggestions for correction are provided where possible.


Not our problem

The Web Accessibility Initiative’s Web Content Accessibility Guidelines are intended “to make web content accessible to people with disabilities.” Yet these proposed guidelines for WCAG 2.0 extend well beyond web content into unrelated technical fields and, indeed, the mind of the author.

Here your contribution can be an expert opinion on how the proposed guideline would apply to your site. Would you fail, pass, or fall somewhere in between? Would it even be possible for you to assess whether or not you comply? How would a Web Content Accessibility Guideline such as this affect your web development?

  1. Do you want the Web Accessibility Initiative dictating to you how “complex” or “unfamiliar” your content might be, or even whether it might be complex at all? If using data tables, won’t you already be using correct table markup?


    Examples of complex information:

    • Data tables,

    • Concepts that are esoteric or difficult to understand,

    • Content that involves several layers.

    unfamiliar content


  2. Abbreviations and acronyms are a problem that may never be satisfactorily resolved, at least not until screen readers — the main sticking point here — are upgraded to handle them better. Meanwhile, the discussion of diacritic marks is an attempt to force authors to write Arabic and Hebrew with the vowel markings that are generally deleted in adult-level writing — again all because screen readers cannot handle the writing system as grownups use it.

    1. Abbreviations and acronyms are clearly identified each time they occur.

    2. Symbols such as diacritic marks that are found in standard usage of the natural language of the content, and that are necessary for unambiguous identification of words, are present or another standard mechanism for disambiguation is provided.

How to contribute

  • If you have anything to contribute to the WCAG 2.0 development process, you can post a message to the WAI-GL mailing list (wai-gl at lists.w3.org).
  • You’re also requested to post to another list, public-comments-wcag20 at w3.org.
  • Both lists have archives on the web (WAI-GL, Public-Comments).
  • There’s also a Bugzilla implementation for WCAG, though you’re not allowed to “discuss” issues there.
  • WCAG holds a few “f2f” meetings each year; the next is in Tokyo.
  • I certainly encourage you to publish comments on your own weblogs, with links sent along to the mailing lists. That will get the message out to more readers, and also put a bit more public pressure on the Web Accessibility Initiative to create better guidelines.

26 Reader Comments

Load Comments