LC-56 DoC negative

We have (as of noon EDT, 18 August 2003) apparently only one outstanding 
negative response to our OpsGL DoC document:  Jon Gunderson's rejection 
(thread starting at [4]) of our disposition of his OpsGL issue, LC-56 [1].

I propose that we (QAWG) move forward as follows.

Part 1:  Considering only OpsGL:
==========

There is only one part of LC-56 [1] which is relevant to WG operations and 
OpsGL:  "This may require having a specific person in charge of defining 
and monitoring the inclusion of accessibility features."

Regardless of the resolution of the broader issue (below), we believe that 
OpsGL should not require such a specific person.  Reasons:

1.) If "defining and monitoring the inclusion of accessibility features" is 
determined to be OUTSIDE of the scope of QA's mission and responsibilities, 
then any such "special person" is outside of the scope of OpsGL (QA-related 
operational aspects of WG life).

2.) If "defining and monitoring the inclusion of accessibility features" is 
determined to be WITHIN the scope of QA's mission and responsibilities, 
then the proposed accessibility duties would automatically fall within the 
job description of the OpsGL-required "QA Moderator".

Considering only OpsGL, then, there is no need for any change.  We reaffirm 
our disposition of this comment, and we will progress OpsGL with the 
outstanding disagreement.

Part 2:  The broader QA/WAI issue(s)
==========

Although it is not related to the narrow and specific question (above) of 
progressing OpsGL, the broader issue that has come up will impact SpecGL 
and possibly TestGL.

That issue could be summarized as:  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 overview is synthesized from JG's statements:

A.) Statements of 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.

Part 3:  QA's Positions on the broader issue(s):
==========

1.) JG's request is clearly beyond the current scope of the QA Framework.
2.) QAWG believes that the definition, documentation, and enforcement of 
accessibility policy is the primary responsibility of WAI.
3.) We have 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 the coordination should 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.) WAI has far more resources than QA, and it is inappropriate to suggest 
that QA should add more responsibility to its already over-taxed resources.
8.) QA questions the appropriateness of submitting a substantial issue of 
scope at this time.  OpsGL and SpecGL are at Last Call, they have been 
available for over 1-1/2 years in approximately 5 published Working Drafts, 
and their scopes have been clearly stated all along.

....etc...

-QAWG


[1] http://www.w3.org/QA/WG/lc-issues#x56
[2]  http://lists.w3.org/Archives/Public/www-qa-wg/2003Aug/0008.html
[3] http://www.w3.org/QA/WG/lc-issues#x55
[4] http://lists.w3.org/Archives/Public/www-qa-wg/2003Aug/0016.html

Received on Monday, 18 August 2003 10:27:26 UTC