W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > May 2006

(unknown charset) A List Apart: "To Hell with WCAG 2"

From: (unknown charset) Joe Clark <joeclark@joeclark.org>
Date: Tue, 23 May 2006 17:13:28 +0000 (UTC)
To: (unknown charset) public-comments-wcag20@w3.org
Message-ID: <Pine.LNX.4.60.0605231708530.14640@aristotle.multipattern.com>
I am submitting my article, published at A List Apart on 22 May 2006, as a 
set of comments on WCAG 2. I will also submit the specific responses I 
wrote for my own site.

<http://alistapart.com/articles/tohellwithwcag2>

[10]To Hell with WCAG 2

by [11]Joe Clark

      * Published in: [12]Accessibility |
      * [13]Discuss this article 

    To Hell with WCAG 2

    The Web Content Accessibility Guidelines 1.0 were published in 1999
    and quickly grew out of date. The proposed new WCAG 2.0 is the result
    of five long years' work by a Web Accessibility Initiative (WAI)
    committee that never quite got its act together. In an effort to be
    all things to all web content, the fundamentals of WCAG 2 are nearly
    impossible for a working standards-compliant developer to understand.
    WCAG 2 backtracks on basics of responsible web development that are
    well accepted by standardistas. WCAG 2 is not enough of an improvement
    and was not worth the wait.

Prepare for disappointment

    If you're a standards-compliant web developer, you already know about
    web accessibility and are familiar with the only international
    standard on that topic, the Web Content Accessibility Guidelines.
    [14]WCAG 1 just celebrated its seventh birthday and is closing in on
    the end of its life. WCAG 1 badly needs revision.

    On 27 April 2006, WAI [15]published the first instalment of the
    interminable sequence of documents required for the revision, WCAG
    2.0, to become a standard.

    If you were hoping for a wholesale improvement, you're going to be
    disappointed. A lot of loose ends have been tidied up, and many
    low-priority guidelines are now pretty solid. The problem here is that
    standardistas already knew what to do to cover the same territory as
    those low-priority guidelines. Where WCAG 2 breaks down is in the big
    stuff. Curiously, though, and perhaps due to meticulous editing over
    the years, the big stuff is well camouflaged and, to an uninformed
    reader, WCAG 2 seems reasonable. It isn't, and you as a working
    standards-compliant developer are going to find it next to impossible
    to implement WCAG 2.

Where to find the documents

    In the great tradition of the W3C, the actual WCAG 2 documents are
    confusing and hard to locate. (I'll also give you pagecounts, as
    printed to U.S. letter-sized PDF from Safari with unchanged defaults,
    as well as wordcounts without markup.) I printed and read all three of
    these documents for this article.
      * [16]Web Content Accessibility Guidelines 2.0 is the actual root
        document and is the only one that is "normative," i.e., a
        standard. It's described, in W3C parlance, as a Last Call Working
        Draft. (72 pages, 20,800 words)
      * [17]Understanding WCAG 2.0 is a document that purports to explain
        WCAG 2. (165 pages, 51,000 words)
      * [18]Techniques for WCAG 2.0 provides "general" techniques. (221
        pages, 88,000 words)

    When compared against typical page dimensions in books, the three WCAG
    2 documents, at 450 pages, exceed the size of each of the books
    published on the topic of WCAG 1, including mine. Additionally,
    according to many blog reports ([19]Snook, [20]Clagnut, [21]Sitepoint,
    [22]Kurafire), [23]Shawn Lawton Henry of the WAI [24]Education &
    Outreach Working Group cautioned attendees at her South by Southwest
    2006 presentation to read only the Understanding document, not the
    actual spec. Since the Understanding document is more than double the
    size of what it purports to explain, this itself may indicate a
    problem with WCAG 2.

    There's a separate document, not updated since November 2005, covering
    [25]HTML techniques. It isn't included in this article. Also,
    "guidelines" in WCAG 1 are now called "success criteria" in WCAG 2, a
    change in nomenclature I will ignore.

    In the discussion below, links to and within these documents were
    difficult to finesse, given their numerous, but still insufficient,
    fragment identifiers. In some cases--paging Steve Faulkner!--no
    sensible title attribute was apparent.

You don't have a lot of time to comment

    After working on WCAG 2 for five years, WAI gave the entire industry
    and all interested parties, including people with disabilities, a
    whopping 34 days to comment on WCAG 2 (until 31 May 2006). While that
    is in excess of the [26]suggested three-week minimum, it isn't long
    enough. The Working Group, moreover, [27]would like you to fill out a
    form, possibly using Excel, for each and every issue you disagree
    with.

    I advise you to simply send mail to [28]public-comments-wcag20@w3.org
    and read the [29]archives of that mailing list (where it's impossible
    to tell exactly who submitted what comment via the WAI form). There's
    a lengthy [30]omnibus list of comments received via the WAI form. I
    also advise people to petition for at least another month's commenting
    time, quoting W3C process back to them (viz., comment periods "may
    last longer if the technical report is complex or has significant
    external dependencies").

The process stinks

    And now a word about process, which you have have to appreciate in
    order to understand the result. The Web Content Accessibility
    Guidelines Working Group is the worst committee, group, company, or
    organization I've ever worked with. Several of my friends and I were
    variously ignored; threatened with ejection from the group or actually
    ejected; and actively harassed. The process is stacked in favour of
    multinationals with expense accounts who can afford to talk on the
    phone for two hours a week and jet to world capitals for meetings.

    The WCAG development process is inaccessible to anyone who doesn't
    speak English. More importantly, it's inaccessible to some people with
    disabilities, notably anyone with a reading disability (who must wade
    through ill-written standards documents and e-mails--there's already
    been a [31]complaint) and anyone who's deaf (who must listen to
    conference calls). Almost nobody with a learning disability or hearing
    impairment contributes to the process--because, in practical terms,
    they can't.

    What WAI is supposed to be doing is improving the web for people with
    disabilities. Something's wrong if many participants work in a climate
    of fear, as they tell me they do. I never hear of similar complaints
    from WAI's other groups. WCAG Working Group is a rogue element within
    the W3C, one that chair Tim Berners-Lee must urgently bring to heel.

    The process is broken, so let's not be surprised that the result of
    that process is broken, too.

Less of a travesty, but still a failure

    If you ever set aside two hours of your life to read a previous
    "draft" of WCAG 2, you were probably baffled and/or infuriated. The
    Working Group has been effective at improving minor guidelines and has
    excelled at making the whole document seem eminently reasonable.
    They've succeeded spectacularly at burying the lede--hiding the nub of
    the guidelines deep within the document. They've done a beautiful job
    at making WCAG 2 look like it will actually work. It won't.

    Based on the three documents I read, taking into account both required
    and suggested practices, let me explain what WCAG really says:
     1. Exactly what a "page" is, let alone a "site," will be a matter of
        dispute.
     2. A future website that complies with WCAG 2 won't need valid
        HTML--at all, ever. (More on that later.) You will, however, have
        to [32]check the DOM outputs of your site in multiple browsers and
        prove they're identical.
     3. You can still use tables for layout. (And not just a
        table--[33]tables for layout, [34]plural.)
     4. Your page, or any part of it, may [35]blink for up to three
        seconds. [36]Parts of it may not, however, "flash."
     5. You'll be able to define entire technologies as a "[37]baseline,"
        meaning anyone without that technology has little, if any,
        recourse to complain that your site is inaccessible to them.
     6. You'll be able to define entire directories of your site as
        off-limits to accessibility (including, in WCAG 2's own example,
        [38]all your freestanding videos).
     7. If you wish to claim WCAG 2 compliance, you must publish a
        [39]checklist of declarations more reminiscent of a forced
        confession than any of the accessibility policies typically found
        today.
     8. Not that anybody ever made them accessible, but if you post videos
        online, you no longer have to provide audio descriptions for the
        blind at [40]the lowest "conformance" level. And only prerecorded
        videos require captions at that level.
     9. Your podcasts may have to be remixed so that dialogue is [41]20
        decibels louder than lengthy background noise. (You don't have to
        caption or transcribe them, since they aren't "[42]multimedia"
        anymore. However, slideshows are now officially deemed to be
        "[43]video," which will come as a surprise to Flickr users.)
    10. You can put a few hundred navigation links on a single page and do
        nothing more, but if you have [44]two pages together that have
        three navigation links each, you must provide a way to skip
        navigation.
    11. You can't use offscreen positioning to add labels (e.g., to forms)
        that only some people, like users of assistive technology, can
        perceive. [45]Everybody has to see them.
    12. CSS layouts, particularly those with absolutely-positioned
        elements that are removed from the document flow, may simply be
        [46]prohibited at the highest level. In fact, source order must
        match presentation order even at the lowest level.
    13. Also at the highest level, you have to [47]provide a way to find
        all of the following:
          1. Definitions of idioms and "jargon"
          2. Expansion of acronyms
          3. Pronunciations of some words
    14. You also have to provide an alternate document if a reader with a
        "lower secondary education level" couldn't understand your main
        document. (In fact, WCAG 2 [48]repeatedly [49]proposes maintaining
        separate accessible and inaccessible pages. In some cases, you
        don't necessarily have to improve your inaccessible pages as long
        as you produce another page.)

    Since these three documents are "drafts," of course all the above can
    change. But really, it won't. A Last Call Working Draft is [50]viewed
    as substantially complete. It is "a signal that... the Working Group
    believes that it has satisfied its relevant technical requirements
    [INS: [and] :INS] has satisfied significant dependencies with other
    groups." The WCAG Working Group is not going to budge on major issues
    at this point.

It's the definitions that sink it

    While WCAG 2 calls for all manner of unrealistic and unproven
    features, those are not what's going to sink the guidelines. Something
    as mundane as definitions will take care of that.

    WCAG 1 was strongly HTML-specific. Everybody recognized that as a
    problem in an age when formats that blind people love to hate, like
    PDF and Flash, are slowly becoming accessible. So WCAG 2 had to be
    technology-neutral.

    But in so doing, it imagined a parallel universe in which the vast
    majority of web content ceased to be plain-Jane HTML, CSS, and
    JavaScript. It envisioned a world in which lots and lots of Flash,
    PDF, and other, as-yet-uninvented formats were available and intended
    to be accessible. To accommodate this dreamworld, WCAG 2 was written
    and rewritten and rerewritten to apply to everything. Along the way,
    it lost the ability to apply to the real things real developers work
    on every day--plain-Jane HTML, CSS, and JavaScript.

    Pop quiz: What do the following terms, given with their official WCAG
    2 [51]definitions, really mean?

    authored unit
           set of material created as a single body by an author

    authored component
           an authored unit intended to be used as part of another
           authored unit

    web unit
           a collection of information, consisting of one or more
           resources, intended to be rendered together, and identified by
           a single Uniform Resource Identifier (such as URLs)

    parsed unambiguously
           parsed into only one data structure

    programmatically determined
           determined by software from data provided in a
           user-agent-supported manner such that the user agents can
           extract and present this information to users in different
           modalities

    Can you translate any of these terms into words that every reader of
    this article understands, like "page," "site," "valid," "well-formed,"
    or "template"? Well, I can't. Amid all these definitions, where are
    the templates we use to create sites composed of valid, well-formed
    pages?

    If you're a standardista working on accessible websites today, are you
    actually, without even knowing it, an author authoring authored units
    to be used in authored components in programmatically-determined web
    units that can be parsed unambiguously?

    Take a look at WCAG 2 and you'll come up with your own checklist of
    malapropisms and incomprehensible passages. In fact, so much of WCAG 2
    is so hard to understand, and almost impossible to apply to real-world
    websites, that WCAG 2 is no better than its predecessor in one
    respect--both documents flunk their own guidelines for clear and
    simple writing.

    If you can't understand the basics of a guideline, and if WCAG 2 in
    general is so aloof from the real web that it can't even bother to use
    words that working developers understand, are you realistically going
    to be able to implement WCAG 2 on your site? Remember, you cannot
    officially fall back on the Techniques and Understanding documents for
    added information. Only the WCAG 2 document itself is "normative." You
    sink or swim based solely on that.

    And if you have trouble understanding WCAG, does this not imply that
    someone could come along with a different interpretation and accuse
    you of violating WCAG, and, by implication, producing an inaccessible
    site? Since that's illegal in some parts of the world, a certain
    degree of clarity is essential, but clarity is something you do not
    get in WCAG 2.

Testability

    If you slog through WCAG 2, you'll notice that even something as
    deceptively simple as that WCAG 1 guideline on [52]clear and simple
    writing isn't there. Nor is there anything actually stronger than that
    guideline. In fact, there's nothing at all along those lines to be
    found in WCAG 2's Principle 3, "Content and controls must be
    understandable."

    You do, however, have to take fanatical care to mark up
    foreign-language passages, idioms, and the like, and if your content
    "requires reading ability more advanced than the lower secondary
    education level," you have to provide "supplementary content" that
    doesn't require that reading level. If you're a learning-disabled
    person, that's pretty much all WCAG 2 is willing to do for you.

    Based on my analysis and on presentations by Gian Sampson-Wild, it
    seems that dyslexics and others with cognitive disabilities have been
    sacrificed on the altar of testing. As WCAG 2 [53]tells us:

      All WCAG 2.0 success criteria are testable. While some can be
      tested by computer programs, others must be tested by qualified
      human testers. Sometimes, a combination of computer programs and
      qualified human testers may be used. When people who understand
      WCAG 2.0 test the same content using the same success criteria, the
      same results should be obtained with high inter-rater reliability.

    "High inter-rater reliability" is not defined. Does it mean eight out
    of ten people? Six? All ten?

    It seems that everybody assumed it would be easy to find "people who
    understand WCAG 2.0" yet who also disagree that a certain segment of
    content is clearly and simply written. I assume it was taken as
    axiomatic that tests of content would seldom achieve "high inter-rater
    reliability," which relies on messy human opinion. The Working Group
    was and is unreasonably fixated on automated testing, in part due to
    the presence on the Working Group of authors of automated testing
    applications and algorithms. The group was able to stomach the reality
    that, for example, alt texts can be evaluated only by humans, but was
    unwilling to accept that the same applies to "content" generally.

    It is harsh but fair to observe that WCAG 2 sells out people with
    learning disabilities so that a tool like Bobby, or a competing or
    successor tool, can test a larger number of criteria with a higher
    success rate.

The creative fiction of multiple levels

    WCAG 1 had three levels of "conformance," which, in typical WAI style,
    were given a total of six names--Priority 1/Level A, Priority 2/Level
    AA (annoyingly written as "Double-A" to get around faulty
    screen-reader pronunciation), and Priority 3/Level AAA ("Triple-A").
    Standardistas eventually figured out that Priorities 1 and 2 were what
    you really needed to make an accessible website; Priority 3 was
    strictly optional (also [54]onerous and [55]impossible to meet in
    principle). Even some governments, like [56]Canada's, require Priority
    2 compliance for their own sites, though it is not necessarily
    achieved.

    When experts carry out evaluations of websites against WCAG 1, most of
    the time they consider the first two priority levels. Few, if any,
    sites pass Priority 3 evaluation; the [57]Disability Rights Commission
    and [58]Nomensa found that no sites tested met Priority 3.

    To a rational observer, all this means that Priorities 1 and 2 in WCAG
    1 are really a single set of rules and Priority 3 is irrelevant and
    unattainable. Getting this idea through the heads of the Working Group
    (or rather, through the head of one of the cochairs) was impossible,
    so in WCAG 2 we're still stuck with three levels. But get this:
    [59]All levels are deemed important.

      Level 1 success criteria:
     1. Achieve a minimum level of accessibility.
     2. Can reasonably be applied to all web content.

      Level 2 success criteria:
     1. Achieve an enhanced level of accessibility.
     2. Can reasonably be applied to all web content.

      Level 3 success criteria:
     1. Achieve additional accessibility enhancements.
     2. Cannot necessarily be applied to all web content.

    To translate: We poor saps misunderstood WCAG 1's priority levels to
    be real priority levels. WCAG 2 considers all of its guidelines
    "essential for some people," though they're still broken up into three
    levels. But actually, if you look closely at the WAI documents:
     1. Even if you comply with all three levels in WCAG 2, [60]you may
        still end up with an inaccessible site.
     2. You never have to comply with [61]more than half of the Level 3
        guidelines.
     3. The WCAG 2 document itself [62]baldly states that "It is not
        recommended that Triple-A conformance ever be required for entire
        sites."
     4. In a circular contradiction, [63]Guideline 4.2.4, at Level 3,
        doesn't even require you to meet Level 3 in some cases.

    Which level would you like to conform to? Please make your selection
    now.

    In a further absurdity, the Working Group couldn't even finesse its
    guidelines to apply to all levels. Some guidelines don't even manifest
    themselves at Level 1, the lowest level. I did a count:
      * Levels 1 + 2 + 3: 7 guidelines
      * No Level 1: 1 guideline
      * No Level 2: 2 guidelines
      * No Level 3: 1 guideline
      * Level 1 only: 2 guidelines
      * (Level 2 only or Level 3 only: Nil)

It's as if web standards never existed

    While people like you and me were labouring in the trenches since
    approximately 1998 to improve web standards--improve support in
    browsers, improve understanding among authors, improve the basic task
    of explaining standards--the WCAG Working Group has been off in its
    parallel universe cooking up guidelines that apply equally ambiguously
    to everything. But the Working Group certainly did take the time to
    exterminate some accepted concepts.

    Yes, [64]we know already: A site with valid HTML [65]is not
    automatically accessible. We've got a couple of fun little example
    pages to look at (by [66]Gez Lemon and [67]Bruce Lawson). But that's
    all they are--examples. In the real world of clueless tag-soup
    developers, the growing minority who understand valid HTML are an
    elite who also understand accessibility. They understand which
    accessibility features you get for free with valid HTML (like alt
    texts, which--yes, we know already--have to be written correctly).
    These developers take the time to include the remaining accessibility
    features anyway.

    They also understand that tag soup produces unpredictable results in
    browsers [68]and in screen readers. They know that a single unencoded
    ampersand, or [69]omitted semicolon, or stray Unicode character on a
    page may knock it into the land of invalid HTML, but those are
    trifling examples not found in tag-soup sites like Amazon and eBay.
    (They know that Amazon and eBay are successful despite their source
    code.) They know that validity is a fragile thing that indeed can be
    blown out of the water by something as simple as a character like an
    , an &nbsp (sic), or an & in the wrong place. They know all that.

    Nonetheless, valid HTML was [70]a second-level requirement in WCAG 1.
    You almost never find it in a commercial site--Nomensa's recent
    survey, which found four examples out of 99 sites it manually checked,
    is the highest I've ever seen. But, as a requirement, it warned
    developers that, while tag soup is the norm, it is not what we want.

    WCAG 2 upends that apple cart completely. You never have to have valid
    HTML in WCAG 2-compliant sites. All that's required is that the page
    be parsed unambiguously ([71]Guideline 4.1--a Level 1 guideline with
    no Level 2 or 3 guidelines). This is [72]supposed to mean "no
    improperly-nested elements," but you'd never know that from the term
    itself.

    In an HTML page, you can keep right on using all the misplaced stray
    characters you want, but you can't nest <p> inside <p>. You do not
    have to use any elements or attributes required by the specification.
    [73]You do not have to use elements according to specification. All
    this spells trouble for the case of forms, an area of constant
    annoyance for screen-reader users. A document made up of nothing but
    divs and spans, if unambiguously parsable, passes WCAG 2 free and
    clear.

    XHTML pages, according to spec, are supposed to stop dead in their
    tracks at the first ill-formed content, but we know they do not do so
    in the real world, where XHTML is treated like a kind of HTML with
    added closing slashes (save for the tiny few perfectionists who serve
    XHTML as XML). So in fact this requirement gives XHTML the same pass
    it gives HTML.

    Does any of that really solve the problem? Or does it have enough of
    an appearance of solving the problem that it could be voted into
    existence by Working Group members from companies like IBM, Oracle,
    and SAP, whose software cannot reliably produce genuine valid HTML?
    (IBM has been [74]actively promoting a DHTML accessibility technique
    that breaks the HTML spec. Oddly, and futilely, the Techniques
    document [75]discourages such a thing.)

    Do you think WCAG 2's guideline is good enough to improve the
    practices of tag-soup developers? Even if valid HTML everywhere all
    the time is unattainable, the fact remains that, in 2006, we have
    never had more developers who understand the concept and are trying to
    make it real on their own sites. WCAG 2 undoes a requirement that,
    were it retained, could be perfectly timed now.

Captioning and audio description for multimedia

    If there's any area in which the application of WCAG 1 was a total
    failure, it's multimedia. People have been quite happy to ignore the
    requirements for captions (for the deaf) and audio descriptions
    (additional narration for the blind), both of which were [76]required
    at the lowest accessibility level. (Actually, it was worse than that
    from a deaf person's perspective. You could get by just with a
    transcript, not actual captions.)

    Captioning and description simply are not found in the wild. When
    there's any access at all, it's through captioning. In this way,
    online multimedia follows TV, home video, and cinema in major
    democracies, where captioning is common and description isn't. (Who
    can forget the irony of AOL's head of accessibility, a blind man,
    announcing captioning on "[77]select" AOL videos, but no audio
    description at all?)

    For a deaf or a blind person who wants to understand multimedia, WCAG
    2 offers no real improvement. The transcript-only loophole has been
    closed, and captions remain a requirement at the lowest level for
    prerecorded video. But instead of audio description, you can get by
    with a figment of the Working Group's imagination called a "full
    multimedia text alternative including any interaction". A discredited
    holdover from WCAG 1, it's [78]apparently a combination of transcript
    of dialogue and sound effects (which blind people don't need),
    transcript of audio descriptions (which deaf people don't need), and
    links to any interactive components in the video.

    The whole thing is supposed to be of help to deaf-blind people, who
    were never surveyed for their preferences, an action I recommended to
    WAI at [79]a face-to-face meeting in 2003. Nor was any user testing
    carried out. (That's all I can tell from published evidence, anyway. I
    sent e-mail inquiries to deaf-blind organizations in several countries
    asking if they'd been surveyed or had any opinions, with no response.)

    There are about three known examples of such a transcript in the
    seven-year history of WCAG (e.g., [80]DigNubia). And there really
    aren't any HTML semantics for such transcripts, unless you wanted to
    push the envelope of the [81]definition list (a [82]banned usage in
    "HTML 5").

    At the next-to-lowest compliance level, suddenly real audio
    descriptions are required and, again suddenly, live video must be
    captioned. Go one step higher and you have to translate your video
    into sign language (which one?) and provide that same imaginary
    transcript, among other things. [83]You never have to describe live
    video.

    And while I've never been a proponent of requiring the hundreds of
    live online radio stations to caption themselves, certainly
    prerecorded podcasts are an obvious source of inaccessible multimedia.
    But actually, multimedia is defined as "audio or video synchronized
    with another type of media and/or with time-based interactive
    components." Your MP3 podcast isn't synchronized with anything, so
    it's exempt. This requirement will satisfy the majority of podcasters
    who ever even bothered to think about accessibility, pretty much all
    of whom decided it was too much trouble even if they liked the idea or
    [84]worked for WAI at the time. The requirement will also ensure that
    the status quo of inaccessible podcasting remains untouched.

Further discussion

    That's enough for one article, I think. But that isn't the end of my
    comments on WCAG 2; you can check [85]my website for ongoing
    additions. This article's comments section, and the tag [86]WCAG2, are
    other ways to comment.

Announcing the WCAG Samurai

    WCAG 2 is not too broken to fix, but we have no reason to think the
    WCAG Working Group will actually fix it. The Working Group is too
    compromised by corporate interests, too wedded to the conclusions we
    see in the current "draft," too broken in general. What you see in
    WCAG 2 now is pretty much what you're gonna get--permanently.

    As such, WCAG 2 will be unusable by real-world developers, especially
    standards-compliant developers. It is too vague and counterfactual to
    be a reliable basis for government regulation. It leaves too many
    loopholes for developers on the hunt for them. WCAG 2 is a failure,
    and not even a noble one at that.

    If this is what we get when WAI tries to rewrite WCAG from scratch,
    maybe there's another option. WCAG 2 does not "replace" WCAG 1 any
    more than XHTML "replaced" HTML. Maybe all we really need to do is to
    fix the errata in WCAG 1. [87]It's been discussed before, but a WCAG
    1.0 Second Edition or a WCAG 1.1 never happened.

    Now, though, I can announce that such errata really are going to be
    published, and my friends and I are going to do the publishing. After
    the manner of Zeldman's CSS Samurai [88]posse, which put CSS layouts
    on the map for browser makers and developers, the [89]WCAG Samurai
    will publish errata for, and extensions to, existing accessibility
    specifications.

    Of course we aren't going to infringe anybody's copyright, but another
    thing we're not going to do is run a totally open process. It's a
    viable model for standards development, one I have championed in
    another context, but in web accessibility it is proven not to work.
    Membership in WCAG Samurai, as in CSS Samurai, will be by invitation
    only. If we want you, you'll hear from us.

    Of course this is unfair to say the least, if not actively elitist and
    hypocritical. Call it as you see it. But this is what we're going to
    try in the hopes of getting the job done, which WAI and its model have
    simply failed to do.
    ISSN: 1534-0295 [107]Copyright  1998-2006 A List Apart Magazine and
    the authors.

References

    1. http://www.alistapart.com/feed/rss.xml
    2. http://alistapart.com/articles/
    3. http://alistapart.com/topics/
    4. http://alistapart.com/about/
    5. http://alistapart.com/contact/
    6. http://alistapart.com/contribute/
    7. http://alistapart.com/feed/
    8. http://alistapart.com/
    9. http://alistapart.com/issues/217
   10. http://alistapart.com/articles/tohellwithwcag2
   11. http://alistapart.com/authors/c/joeclark
   12. http://alistapart.com/topics/userscience/accessibility/
   13. http://alistapart.com/comments/tohellwithwcag2/
   14. http://www.w3.org/TR/WAI-WEBCONTENT/
   15. http://lists.w3.org/Archives/Public/w3c-wai-ig/2006AprJun/0023.html
   16. http://www.w3.org/TR/WCAG20/complete.html
   17. http://www.w3.org/TR/UNDERSTANDING-WCAG20/
   18. http://www.w3.org/TR/WCAG20-TECHS/
   19. http://www.snook.ca/archives/other/sxsw_2006_day_2/
   20. http://www.clagnut.com/blog/1691/
   21. http://www.sitepoint.com/blogs/2006/03/12/sxsw-day-two-still-going-strong/
   22. http://kurafire.net/log/archive/2006/04/12/web-2-1-making-web-20-accessible
   23. http://www.w3.org/People/Shawn/
   24. http://www.w3.org/WAI/EO/
   25. http://www.w3.org/TR/WCAG20-HTML-TECHS/
   26. http://www.w3.org/2004/02/Process-20040205/tr.html#last-call
   27. http://www.w3.org/WAI/WCAG20/comments/
   28. mailto:public-comments-wcag20@w3.org
   29. http://lists.w3.org/Archives/Public/public-comments-wcag20/
   30. http://www.w3.org/WAI/WCAG20/comments/viewdata_all.php
   31. http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0184.html
   32. http://www.w3.org/TR/WCAG20-TECHS/#F28-procedure
   33. http://www.w3.org/TR/WCAG20-TECHS/#N11001
   34. http://www.w3.org/TR/WCAG20-TECHS/#N11138
   35. http://www.w3.org/TR/WCAG20/complete.html#time-limits-blink
   36. http://www.w3.org/TR/UNDERSTANDING-WCAG20/#seizure-does-not-violate-terms
   37. http://www.w3.org/TR/WCAG20/complete.html#baseline
   38. http://www.w3.org/TR/WCAG20/complete.html#conformance-scoping
   39. http://www.w3.org/TR/WCAG20/complete.html#conformance-required
   40. http://www.w3.org/TR/WCAG20/complete.html#N10516
   41. http://www.w3.org/TR/WCAG20/complete.html#visual-audio-contrast-noaudio
   42. http://www.w3.org/TR/WCAG20/complete.html#multimediadef
   43. http://www.w3.org/TR/WCAG20/complete.html#videodef
   44. http://www.w3.org/TR/WCAG20/complete.html#navigation-mechanisms-skipcb
   45. http://www.w3.org/TR/UNDERSTANDING-WCAG20/#content-structure-separation-programmatic-intent-head
   46. http://www.w3.org/TR/WCAG20-TECHS/#N100C7
   47. http://www.w3.org/TR/WCAG20/complete.html#N107C8
   48. http://www.w3.org/TR/WCAG20/complete.html#N1089F
   49. http://www.w3.org/TR/WCAG20-TECHS/#F19
   50. http://www.w3.org/2004/02/Process-20040205/tr.html#last-call
   51. http://www.w3.org/TR/WCAG20/complete.html#glossary
   52. http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-simple-and-straightforward
   53. http://www.w3.org/TR/WCAG20/complete.html#conformance
   54. http://lists.w3.org/Archives/Public/w3c-wai-ig/2000OctDec/0563.html
   55. http://lists.w3.org/Archives/Public/w3c-wai-ig/2000OctDec/0555.html
   56. http://www.tbs-sct.gc.ca/clf-nsi/inter/inter-01-01_e.asp
   57. http://joeclark.org/dossiers/DRC-GB.html#div-3185
   58. http://www.nomensa.com/news/at-nomensa/2006/4/ftse-100-websites-fail-accessibility-requirements.html
   59. http://www.w3.org/TR/WCAG20/complete.html#conformance
   60. http://www.w3.org/TR/WCAG20/complete.html#conformance
   61. http://www.w3.org/TR/WCAG20/complete.html#conformance-reqs
   62. http://www.w3.org/TR/WCAG20/complete.html#N10471
   63. http://www.w3.org/TR/WCAG20/complete.html#accessible-alternatives-level2
   64. http://www.bestkungfu.com/archive/date/2005/11/on-accessibility-and-validity/
   65. http://www.w3.org/WAI/GL/2005/06/validity-accessibility.html
   66. http://juicystudio.com/experiments/invalid.html
   67. http://csszengarden.com/?cssfile=http://www.tastydirt.com/zen/sample.css
   68. http://blog.fawny.org/2004/05/13/screen-reader-code/
   69. http://www.bestkungfu.com/archive/date/2005/06/a-principled-argument/
   70. http://www.w3.org/TR/WCAG10-TECHS/#tech-identify-grammar
   71. http://www.w3.org/TR/WCAG20/complete.html#N1085F
   72. http://www.w3.org/TR/WCAG20-TECHS/#F28-failex1
   73. http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0187.html
   74. http://blog.fawny.org/2005/08/22/tabindex/
   75. http://www.w3.org/TR/WCAG20-TECHS/#N10F37
   76. http://www.w3.org/TR/WCAG10-TECHS/#tech-synchronize-equivalents
   77. http://www.corp.aol.com/accessibility/closedcaptions.html
   78. http://www.w3.org/TR/UNDERSTANDING-WCAG20/#media-equiv-audio-desc-intent-head
   79. http://joeclark.org/access/webaccess/WCAG/f2f/
   80. http://www.dignubia.org/galleries/transcript.php?p=5
   81. http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.3
   82. http://whatwg.org/specs/web-apps/current-work/#the-dl
   83. http://lists.w3.org/Archives/Public/w3c-wai-gl/2006AprJun/0195.html
   84. http://www.bestkungfu.com/archive/date/2005/03/how-to-help-a-podcaster/
   85. http://joeclark.org/access/webaccess/WCAG/
   86. http://technorati.com/tag/WCAG2
   87. http://lists.w3.org/Archives/Public/w3c-wai-gl/2003OctDec/0381.html
   88. http://archive.webstandards.org/css/members.html
   89. http://WCAGSamurai.org/
   90. http://alistapart.com/about/kevincornell
   91. http://alistapart.com/topics/userscience/accessibility/
   92. http://alistapart.com/comments/tohellwithwcag2/
   93. http://joeclark.org/access/?ALA
   94. http://joeclark.org/book/?ALA
   95. form field = text entry field
   96. form field = image-submit button
   97. form field = checkbox
   98. http://alistapart.com/topics/code
   99. http://alistapart.com/topics/content
  100. http://alistapart.com/topics/culture
  101. http://alistapart.com/topics/design
  102. http://alistapart.com/topics/process
  103. http://alistapart.com/topics/userscience
  104. http://www.coudal.com/deck/
  105. http://textdrive.com/
  106. http://happycog.com/
  107. http://alistapart.com/copyright/
Received on Tuesday, 23 May 2006 17:13:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:06 UTC