Joe Clark: Accessibility | Design | Writing

Response to ‘Understanding WCAG 2.0’

This document contains my comments on the WAI publication Understanding WCAG 2.0.


Endorsement of “non-W3C technologies”

A deficiency of WCAG 1 was its chauvinism toward anything not invented by the W3C. They pretty much didn’t want you to use any “non-W3C technologies”; there’s a whole guideline telling you not to. WCAG 2 tries to be technology-neutral. In so doing, it authorizes the use of “HTML” that was never ratified by a specification, notably embed.

While this is the only reliable method to include multimedia on a Web page (still, in 2006), is univerally understood by graphical browsers, and can easily be made legal via a custom DTD, it still isn’t real HTML. I find its inclusion curious given WAI’s ideology of yore. (Elsewhere, the Understanding document lists the blink element as a failure method. That isn’t real HTML either, thankfully.)


A Web page has a field that automatically updates with the latest headlines in a rotating fashion. There is a slider that allows the user to slow the update rate by as much as 10.

A slider? That requires a mouse, not to mention full vision.

Time limits

In circumstances where a sign-language interpreter may be relating audio content to a user who is deaf, control over time limits is also important.

Then that isn’t an issue of Web content anymore. Hiring a human aide to make a site accessible to you is no longer our problem.

Flashing (but not blinking)

A movie with a scene involving very bright lightning flashes is scripted so that the lightning only flashes two times.

Yes, WAI wants you to rewrite your script.

Text alternatives

  1. [For n]on-text content that is multimedia... it is important that users know what it is when they encounter it on a page so they can decide what action if any they want to take with it. A text alternative that describes the multimedia and/or gives its title is therefore provided.

    How do I do that with, say, embed, which permits no fallback content? (Of course there’s noembed, but, since all graphical browsers understand embed, noembed content will never be displayed. In any event, there is no actual or official specification for embed and especially noembed.)

    Does this not mean I have to label each video in plain text?

  2. Providing what description is possible is also desired. If the intent of the author in creating the content – or the intent of the page author in putting the content on the page – is known and can be described, this is also very useful

    “Intent of the page author”? What is this talking about?

  3. Linking to live textual information, e.g., if it is a traffic Webcam, linking to a site that provides textual traffic reports

    If my Webcam is pointed out my window and depicts my obscure street or intersection, exactly how am I going to locate a traffic-report site that covers my neighbourhood? And how is that actually “equivalent” given that a sighted visitor can watch traffic in real time, while a “textual traffic report” has to be written and published post-facto and can never keep up?

  4. And now, the biggest failure of the section on text equivalents. I’ve been warning WCAG Working Group about this topic for years. The fact that the following example made it this far into the writing process demonstrates that the Working Group simply will not accept reality.

    A data chart: A bar chart compares how many widgets were sold in June, July, and August. The short label says, “Figure one – Sales in June, July and August.” The longer description identifies the type of chart, provides a high-level summary of the data comparable to that available from the chart, and provides the data in a table.

    It is obviously a lost cause to try to explain to WCAG that diagrams and data are not interchangeable. We create diagrams because data are too hard to understand. To use an analogy over again, diagrams and data are like a suitcase that can be unpacked but not easily repacked. If data were understandable by themselves, we wouldn’t make a chart.

    I can assure the Working Group that giving nondisabled people a really nice chart and disabled people a table with 10,000 or more data points does not constitute equality in any sense. Moreover, some data can be understood only if transformed (as by plotting on a logarithmic scale), which is the sort of thing that simply cannot be expressed understandably in numbers.

    I am aware that the National Braille Association has authorized WAI to publish parts of its training manual concerning the rendition of charts and graphs in audiobooks. I have seen no evidence that those techniques are viable on the Web. Given that they seem to work fine for audiobooks, I would be interested to see any such evidence.


  1. People who are deaf, are hard of hearing, or who are having trouble understanding audio information for any reason can read the text presentation or (in the future) have it translated and presented as sign language by assistive technology.

    No such vapourware technologies of text-to-sign translation will be available and reliable during the lifetime of WCAG 2. (If you think otherwise, here’s something for you: Can you make it work in Quebec Sign Language?)


    Captions may be generated using real-time text translation service (stenographic or, in the future, speech-to-text with corrections).

    Who’s gonna do those corrections (in real time, no less)? And at what point in the “future” will this be developed? The existing technique of speaker-dependent speech recognition, known as voicewriting, could be included here if defined properly.

  2. Providing open captions that are embedded directly in the video stream

    “Embedded”? As by using embed?

    What are they trying to get at here? Burned-in open captions (a nice, easy, understandable terminology that could be used) or encoded captions that always display even if the viewer doesn’t want them (a much rarer case, similar to forced subtitles on DVD)?

  3. Providing closed captions using any readily-available media format that has a video player that is free of charge and supports closed captioning

    Funny... Jaws isn’t free. Why are we restricted to the usage of free players when accessibility software in other contexts is expensive?

  4. I appreciate the fact that my work is cited in this document – Best Practices in Online Captioning and Standard Techniques in Audio Descriptions (sic – it’s actually singular). I note, though, that the only contributors to these “Related Resources” that merit a real byline are the National Braille Association and... Gregg Vanderheiden, dear coleader of the WCAG Working Group.

    • An audio file begins playing automatically when a page is opened. However, the audio can be stopped by the user by selecting a “silent” link at the top of the page.

    • An audio file begins playing automatically when a page is opened. However, the audio can be stopped by the user by selecting a “silent” link at the top of the page.

    Why does this section not cover the more typical scenario, a Flash splash page with sound that plays and then stops, or that plays and can be turned off only by a hard-to-find control, often at the bottom of the page? (I’ve also seen such controls appear only after the sound has finished playing.)

Linguistics & typography

  1. A sequence is meaningful if the order of content in the sequence cannot be changed without affecting its meaning. The order of words in sentences and sentences in paragraphs, for instance, is always meaningful.

    Not in free-word-order languages, though many of those do tend to converge on certain preferred word orders.

  2. Ensure that numerals or other lookalike glyphs are not used in place of letters

    There goes your l33tspeak, h4xorz! (\/\/C4G iz teh sux0r @nyw@y111oneoneone)

  3. Failure of SC 1.3.5 due to using a non-text mark alone to convey information

    Note: Glyphs are non-text marks.

    This is insane. Unicode defines glyph as:

    1. An abstract form that represents one or more glyph images.
    2. A synonym for glyph image. In displaying Unicode character data, one or more glyphs may be selected to depict a particular character.

    In Web content, glyphs are text marks.

  4. Using an image for “○” (circle mark) or “×” (cross mark) instead of text and providing alternative text for the image which describes the meaning of its mark

    Those circle and cross marks are text. Even the Understanding document itself uses them as such. (The “cross mark” is incorrectly chosen. What is depicted is a multiplication symbol.) WAI may wish to look at Unicode characters like U+2611 ☑ BALLOT BOX WITH CHECK.

You are here: joeclark.orgCaptioning and media access
Web accessibilityWCAG → Response to ‘Understanding WCAG 2.0’

Updated 2006.05.23

Homepage: Joe Clark Homepage: Joe Clark Media access (captioning, Web accessibility, etc.) Graphic and industrial design Journalism, articles, book