(unknown charset) Response to "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 [3]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


      [INS: [For n] :INS] 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?

      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?

      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.



      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.

      Providing open captions that are embedded directly in the video
        "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)?

      Providing closed captions using any readily-available media format
      that has a video player that is free of charge and supports closed
        Funny... Jaws isn't free. Why are we restricted to the usage of
        free players when accessibility software in other contexts is
     4. I appreciate the fact that my work is cited in this document -
        [4]Best Practices in Online Captioning and [5]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

           + 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


      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
        Not in free-word-order languages, though many of those do tend to
        converge on certain preferred word orders.

      Ensure that numerals or other lookalike glyphs are not used in
      place of letters
        There goes your l33tspeak, h4xorz! (\/\/C4G iz teh sux0r

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 [6]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.

      Using an image for "0m" (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 [7]multiplication
        symbol.) WAI may wish to look at Unicode characters like U+2611

    You are here: [8]joeclark.org -> [9]Captioning and media access ->
    [10]Web accessibility -> [11]WCAG -> Response to `Understanding WCAG

    Updated 2006.05.23


    1. LYNXIMGMAP:http://joeclark.org/access/webaccess/WCAG/response1_Understanding-WCAG2.html#joeclark_angie_02IX_Map
    2. http://www.w3.org/TR/UNDERSTANDING-WCAG20/
    3. http://www.w3.org/TR/WAI-WEBCONTENT/#gl-use-w3c
    4. http://www.joeclark.org/access/captioning/bpoc/
    5. http://www.joeclark.org/access/description/ad-principles.html
    6. http://www.unicode.org/glossary/#glyph
    7. http://www.fileformat.info/info/unicode/char/00d7/index.htm
    8. http://joeclark.org/
    9. http://joeclark.org/access/
   10. http://joeclark.org/access/webaccess/
   11. http://joeclark.org/access/webaccess/WCAG/

Received on Tuesday, 23 May 2006 17:14:27 UTC