Editorial, general comments on WCAG 2.0 20030624 draft

Greetings,

Here is a small review of the june 24 2003 draft of WCAG 2.0.

** disclaimer **
I am not an accessibility expert, so my comments are more focused on 
the quality of the specification (document) itself rather than the 
quality of the guidelines. I just read the document a few times and 
took notes, so the review is not very structured. I hope it will be 
useful nonetheless.
I may add comments later, as time permits.



** General comments **
This draft is good. It did not impress me as much as the previous time 
I reviewed a WCAG2 draft, but that may just be because I'm getting used 
to this specification. Generally speaking, my impression was that 
reading the spec felt clearer, but not as pleasant. Just an impression, 
though.


** Editorial comments **
Status: comments list not consistent with what was mentioned in the 
e-mail announcement I received.

"Priorities and Techniques" : [[This WCAG 2.0 Working Draft does not 
assign priorities to checkpoints, as did WCAG 1.0.]]. Did 1.0 assign or 
not assign? It may be that my english is not good enough. Or it may be 
that the comma could cause some confusion.

idem.: [[Instead, there are two types]]. Specify types "of what?".

Conformance section :"becomesless" (missing white space)

1.2 : requirements are listed as 1,2,1,2,3,4. Looks strange.

3.1: the french phrase is, rather, "je ne sais quoi"

3.3: is the first list after the checkpoint's title a conformance 
requirement or a best practice? Missing heading I suppose.


** Notes **
Conformance section : Does look good, even when quickly running the QA 
Specification checklist against it.
The conformance section could use minor improvements such as:
	- adding a conformance disclaimer
	- moving "Sites that conform to WCAG 1.0" out of conformance section, 
maybe...
	I'd suggest renaming it too (using terms such as "transition"?)
I'm not really fond of the idea of CORE+. I would recommend, if you go 
with that scheme, that CORE+ claims MUST come with a full list of what 
requirements are met. CORE+n sounds like an invitation to foul play. I 
understand the logic behind it but it doesn't seem worth the 
complication and complications.

1.2: seems a bit on the verge of technology independent. Would be nice 
if the requirements could be simplified and most of the existing 
wording could be moved to examples/techniques.

1.6: suggested example: as it is possible with graphics to change the 
contrast, it is possible (if the speech was recorded separately, or 
not, thanks to sound processing algorithms) to let the end user choose 
whether (s)he wants the background sound a all, and leave the 
possibility to set the contrast between the two.

3.2: I'm  almost certain you have discussed that to death already, but 
"first time it appears" only really makes sense for time-dependent 
content, doesn't it? I would suggest a rewording (or a best practice?) 
stating that for interactive, asynchronous or hypertext content, a 
glossary is recommended over a definition "the first (likely) time a 
word appears".

3.3: "not more than necessary" is hardly testable. Not certain what to 
suggest, maybe a rewording of the checkpoint's title to talk about 
review rather than [[written to be no more complex than is necessary]]

4.1: The language used, itself, must be clearly defined (with 
appropriate MIME headers, doctype declaration, etc).

All for now, keep up the good work.
-- 
olivier

Received on Wednesday, 6 August 2003 04:49:06 UTC