Working together for standards The Web Standards Project

The comment period for WCAG 2 has been extended to Thursday, June 22. If you are thinking about giving feedback, I suggest reading the directions for commenters.

The ATF will be publishing a broader set of issues shortly, and working to help the WCAG Working Group cover narrower technical issues as we go.

I have reviewed the current Last Call Working Draft. My opinions, and those of the rest of the ATF, are on the way. In a nutshell, I think there’s a lot more good than bad in the document. Its key problems are not its technical faults, which can be identified and rewritten, but general usability issues, which cause it to be unapproachable by new readers.

My advice to commenters is to separate the two: document technical issues you may have, then give a general comment on how you would like this content structured, and what kind of supporting educational and reference materials you will need to support it.

Just don’t expect the group to produce all of that material. We shouldn’t demand that they produce a spec as concise and comprehensive as the US Constitution, but as readable as a Dummies book. We need books and tutorials and code samples, but anybody who understands the subject can produce those later.

The most important requirement of WCAG 2 is that it be technically solid. If it is long, dense, and no fun to read, but complete and accurate, that’s what we want. Specifications specify. We should expect the working group to work toward that singular goal: not policy considerations, not flexible baselines, not complex conformance and scoping schemes, not flowery prose, not measures for the immeasurable. WAI has the support of many, many people who can explain how to do the work, once that core set of requirements is established. The Working Group shouldn’t be responsible for doing any more than defining the issues and testing their solutions. That’s a big enough job by itself.

Your Replies

#1 On May 26th, 2006 3:14 pm Joe Clark replied:

Which is actually the case: WCAG 2 has general usability faults that cause it to be unapproachable or it is naturally long, dense, and no fun to read because specifications *specify*?

#2 On May 26th, 2006 3:35 pm WaSP Member mattmay replied:

Both.

#3 On May 26th, 2006 6:49 pm Tanny O'Haley replied:

When writing specifications I believe that it is a good idea to create examples so that you can see if it works in the “real” world. To be widely accepted, text should be clear and to the point. I believe that WCAG 2 is a failure in that is unclear and not to the point. Not to mention Joe Clark’s To Hell with WCAG 2 article at A List Apart.

#4 On May 26th, 2006 6:51 pm Tanny O'Haley replied:

When writing specifications I believe that it is a good idea to create examples so that you can see if it works in the “real” world. To be widely accepted the text should be clear and to the point. I believe that WCAG 2 is a failure in that it is unclear and not to the point.

#5 On May 26th, 2006 7:42 pm Scott L Holmes replied:

In case you missed it, be sure to read Joe Clark’s review of WCAG2: To Hell with WCAG 2. Did I say review? I meant vociferation; yeah, vociferation.

#6 On May 27th, 2006 2:50 am Bruce Lawson’s personal site   : Grump. replied:

[...] Update: Actually, it turns out I’ve got another three weeks to finish the WCAG 2 reading. The deadline for comments has been extended by three weeks to Thursday 22 June 2006. [...]

#7 On June 1st, 2006 1:42 am Karl Dubost replied:

Tanny,

That’s an interesting comment: “When writing specifications I believe that it is a good idea to create examples so that you can see if it works in the “real” world.”

There are many ways to develop a technical specification. Keep in mind that WCAG 2.0 is a Last Call Working Draft. The next step is usually “Candidate Recommendation” (CR). During the CR phase, most of the time, W3C WGs produce a test suite for the technology. It means a series of test cases (what you label examples) which shows if the techniques/features are implementable. When these test cases have been produced, we can check if the techniques/features are implementable and produce an implementation report.

It is also a very good way to review a specification. When one’s doesn’t agree with a feature in a specification, the best way to demonstrate that it has flaws or that it is underspecified, is to create a test case. Then it’s easier to articulate the discussion on a concrete example.

I encourage any person commenting to create concrete test cases when sending a comment, it helps a lot to move forward the discussion. A specification is a difficult and long process, it is even more difficult when the topic is popular (CSS/HTML/Accessibility).

#8 On June 2nd, 2006 1:34 am Bruce Lawson’s personal site   : WCAG 2.0: when I want a beer, don’t give me shandy replied:

[...] There’s been some excellent discussion about the last call for comments on WCAG 2.0, both on the Web (see Joe Clark’s “To Hell with WCAG 2” and on w3c lists), and also in the hollowed-out volcano where the WaSP Accessibility Task Force meet. The fact that the w3c have extended the review period shows that they’re listening to legitimate criticism. [...]

#9 On June 10th, 2006 12:52 pm Even academics can’t understand it – Le «blog personnel» de Joe Clark replied:

[...] and wouldn’t need a set of cheat sheets treble or quadruple the length of the original. ☛ 2006.06.10 12:48 — Category(ies): Research, WCAG2 Recent postings← PreviousCitroën ClusterPhenomenonNext → [...]

Post a Reply

Comments are closed.