QA-WAI issues


This position was endorsed by QAWG in the 20030903 telecon.

This position has derived from discussion of a couple of specific Last Call 
issues submitted from WAI participants ([3] and [1]).  In email discussion, 
it has evolved as a bigger bigger question than a simple QAF question.

About the broader QA-WAI issue(s)

The broader QA-WAI issue that has come up will impact SpecGL and possibly 

That issue could be summarized as follows:  is it within the scope, 
responsibility, authority and mission of QA to define W3C-wide policy 
mandating accessibility features within all W3C technologies, and to 
document and enforce that policy through its QA Framework guidelines documents?

This issue synopsis is synthesized from JG's statements:

A.) "Description" in the two issues raised against OpsGL and SpecGL, LC-56 
[1] & LC-55 [3]

B.) Statements in rejecting QAWG' disposition of those comments [4]:

>"It seems to me that part of the quality assurance process should be to 
>make sure that the needs of people with disabilities is taken into account 
>as part of the recommendation process ... [and] ... based on the 
>resolution [1] that anything a working group does not want to test, they 
>can just make an informative part of their specification ... [and] 
>...  that your resolution basically says that a working group does not 
>need to deal with accessibility issues if they leave them out of the 
>specification, putting the burden back on the limited WAI resources to 
>pursue the working group for accessibility issues."

For further background, the current scope of OpsGL:

>The scope of this specification is a set of verifiable requirements for 
>the process and operational aspects of the quality practices of W3C 
>Working Groups. The primary goal is to help the W3C Working Groups (WGs) 
>with the planning, development, deployment, and maintenance of conformance 
>test materials (TM).

For further background, the current scope of SpecGL:

>The scope of this document is a set of requirements for W3C Technical 
>Reports (TRs) that if satisfied, will enhance the clarity, 
>implementability, and testability of TRs. It describes what goes into a TR 
>with respect to conformance and conformance topics, dealing with how a TR 
>establishes, defines, and presents its conformance policy.

QA's Positions on the broader issue(s):

1.) The requests in LC-55, LC-56, and subsequent email are clearly beyond 
the current scope(s) of the QA Framework.
2.) QAWG believes that the definition, documentation, and enforcement of 
accessibility policy is the primary responsibility of WAI.
3.) QAWG has not seen any convincing argument that these primary 
responsibilities should be transferred to QA.
4.) QA should coordinate with WAI, as well as I18N, multi-modal, etc.
5.) The nature of optimal coordination would be as follows:  WAI defines 
the policies and gets them endorsed by W3C as binding requirements on the 
WGs; when the WGs write Recommendations in which the policies are to be 
testable conformance requirements, QA helps to ensure that the 
specifications meet minimal criteria of clarity and testability, and that 
derived conformance test suites accurately cover the requirements.
6.) The QA Framework is not the place to define, document, and enforce 
accessibility policy.
7.) The OpsGL and SpecGL documents clearly state their scope. Since these 
documents have been available for over 1-1/2 years in approximately 5 
published Working Drafts, and are now in Last Call, it would not be 
appropriate to broaden their scope at this late stage

-Lofton Henderson
(for QAWG)


Received on Wednesday, 3 September 2003 14:32:51 UTC