- 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   (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