Comments on ATAG 2.0 Last Call Working Draft

Hi,

Below are my two eurocents worth of comments, 
copied from the WCAG Feedback form 
(http://www.w3.org/2002/09/wbs/35422/20070111ATAG/results).

Comments on substance:
* Content Type-Specific WCAG Benchmark: when a 
conformance claim references a non-W3C benchmark, 
and this benchmark disappears (so no one can 
check the claim), how does this affect the 
validity of the conformance claim? If the 
benchmarks moves to a different URL, how does 
this affect the validity of the conformance claim? Please specify.

* WCAG Techniques documents can be used as 
benchmarks referenced by conformance claims, but 
the WCAG 2.0 techniques documents are meant to 
evolve even after WCAG 2.0 is finalised. So if 
conformance claims reference benchmarks that 
evolve, references should always be to dated 
versions (e.g. dated URLs instead of "current 
version URLs" on W3C servers). (Or is that 
covered by § 3.c of "Components of an ATAG 2.0 Conformance Claim"?)

Editorial comments:
* Colons are not necessary to introduce a list 
that is just the next phrase in the syntactic 
structure, so the colons can be removed from teh 
following locations: "including, but not limited 
to:" (Introduction); "This document consists of:" 
(Introduction); "ATAG 2.0 defines an 'authoring 
tool' as:" (Definition of authoring tool); 
"authors and end users may:" (Role of authoring 
tools...); "indicate whether it is either:" 
(Components of ... Conformance Claim).
* B.1.4. The antecedent of "it" is ambiguous (the 
authoring tool or the content). Fortunately, the 
rationale and the success criterion clarify that "it" refers to the content.
* B.3.1 - success criterion 2. "that does not 
conforms" should be "that does not conform".
* Conformance claim § 3.b.ii: full stop at the end is missing.


One additional comment that I forgot yesterday:
When referencing documents as a benchmark, should 
those documents fulfil certain requirements? The 
WCAG 2.0 Techniques document uses a format that, 
for example, always requires a test procedure and 
expected results. It seems useful to define (at 
least some) requirements that benchmark documents need to fulfil.


Best regards,

Christophe


-- 
Christophe Strobbe
K.U.Leuven - Departement of Electrical 
Engineering - Research Group on Document Architectures
Kasteelpark Arenberg 10 - 3001 Leuven-Heverlee - BELGIUM
tel: +32 16 32 85 51
http://www.docarch.be/ 


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Received on Friday, 12 January 2007 15:00:28 UTC