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

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/