SpecGL review

Review of QA Framework: Specification Guidelines, W3C Working Draft 22
November 2004 [1]
[1] http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/

The document is well formatted and easy to comprehend. The style of the
recommendations and good practices is well thought out and
made the review straightforward. Keeping the good practices in the same
document as the recommendations highlights the importance and value of
the good practices.

Most of our comments are requests for clarification about WCAG 2.0
conformance to SpecGL the rest are suggestions for changes to SpecGL or
comments highlighting things that we liked in SpecGL.

Comment #1:
About section: 4.3 Requirement A
It seems that "extensibility" of WCAG 2.0 is related to policy makers
adopting or extending the criteria of WCAG 2.0. For example, JIS
creating additional success criteria specific to Japanese accessibility
issues.  Is this correct or does it not apply?


Comment #2:
About section: 4.4 Requirement A - "deprecated features"
Does "Mapping Between WCAG 1.0 and the WCAG 2.0 Working Draft" [2]
satisfy this requirement? Some of the WCAG 1.0 Checkpoints have evolved
into WCAG 2.0 Techniques while others are likely to be deprecated.
However, because the style is so different between WCAG 1.0 and WCAG
2.0, we are not able to include WCAG 1.0 Checkpoints directly in WCAG
2.0 in a way that makes sense and would allow us to mark them as
deprecated (in the WCAG 2.0 spec).
[2] <http://www.w3.org/WAI/GL/2004/11/19-mapping.html>


Comment #3: The "Normative Parts" table [3] provides an excellent visual
explanation of what is normative and informative. [We will suggest WCAG
WG look at and consider using something like this.]
[3] <http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/#normative-parts>


Suggestion #4:
About: General
The printed document is 75 pages long, and it is easy to get lost while
trying to find a specific requirement or good practice.
Request: increase the levels of the Table of Contents for Guidelines
section.


Question #5:
About: General
SpecGL does not mention the need to consider accessibility while writing
a spec, particularly the need for XML-based vocabularies to conform to 
something like the XML Accessibility Guidelines.
Request: an additional requirement. For example, consider adding a
Requirement to 1.1:
<proposal>Address Accessibility
What does it mean?
Accessibility must be encouraged by the Working Group.  The benefit of
addressing accessibility is the increased likelihood that both user
agents and authoring tools will implement the accessibility features of
the specification from the beginning.  Otherwise, it make take several
revisions before software addresses accessibility features, leaving
people with disabilities behind.  Formalizing the position of the
Working Group by a clear defined section and prose removes ambiguities
for the specification users about the possibility of addressing
accessibility. Refer to the XML Accessibility Guidelines.
</proposal>

Note: There are issues with this proposal and this is a request to start 
a dialog to help us figure out exactly what should be required.  For 
example, XAG is a good place to begin discussion, but because we are 
unsure of its future we are unsure about recommending its inclusion. We 
also think the issues raised/possible opportunities to address with 
SpecGL might go beyond what is currently in the XAG. Therefore, we (the 
WAI CG or at a minimum the PFWG) request the opportunity to discuss this 
issue with you.


Question #6:
About: 2.2 Requirement A: Identify who or what will implement the
specification.
Instead of "Who or what?" maybe it should be "who and/or what?" For WCAG
2.0, not only will developers claim conformance dependent on the use of
technologies (like HTML, CSS, etc.) [i.e., "what"], but organizations
may want to make a conformance claim (about their content) [i.e.,
"who"].  Perhaps this requirement needs clarification.


Question #7:
About: Section 4 Managing Variability.
Since we are not writing a language, we were  not sure how we would
apply this to a recommendation like WCAG 2.0. We seem to manage
variability through conformance to three levels of Success Criteria: in
some instances a success criterion does not apply either because it is
at a higher level of conformance (than the author is aiming for) or the
technology being addressed by the success criterion is not being used in
the Web content for which the conformance claim is made. Is this the
correct interpretation? By using success criteria do we address the
requirements in this section?


Question #8: 5 Good Practice e: "Use formal languages and define which
from prose and formal languages has priority."
This sentence is ambiguous. Propose using: "Use formal languages and if
also using prose, clarify if  prose or formal language has priority."

Wendy Chisholm
Jenae Andershonis (JenaeA@microsoft.com)
For the WAI CG

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Tuesday, 1 February 2005 22:43:19 UTC