W3C home > Mailing lists > Public > www-qa@w3.org > May 2005

Re: Answer to WAI CG on Address Accessibility in Requirements

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Wed, 25 May 2005 18:17:04 -0400
Message-Id: <p06110407beba96d11cf3@[10.0.1.2]>
To: www-qa@w3.org
Cc: w3c-wai-cg@w3.org

At 2:51 PM -0400 5/11/05, Karl Dubost wrote:
>Dear Wendy,
>
>Thanks for your comments on the Last Call version of the QA Framework:
>Specification Guidelines[0] - 22 November 2004
>
>After two weeks from now (on May 18, 2005), the lack of answer will 
>be considered as if you had accepted the comment.

Wendy has allowed me to serve as scribe for this reply. Your
disposition was discussed a bit on the WAI CG teleconference on 18
May and the following reply has been discussed, again for a limited
time but meeting with rough consensus of those who have responded, on
the WAI CG email list.
http://lists.w3.org/Archives/Member/w3c-wai-cg/2005AprJun/thread.html#73


<reply>
<meta name="rfc2822:In-Reply-To" 
value="http://www.w3.org/mid/425D4FEE-3091-4BF7-BADD-A147F52D1BAA@w3.org"/>

<summary
class="executive overview">

<section>
<title>Agreement in principle</title>

The WAI CG agrees with the principle of the resolution as we
understand it.  This is

- The scope of this document will not include imposing accessibility
requirements on the developers of specifications.  That authority
will flow from other sources such as the Process Document, the
Architecture Document, the Recommendations developed by the
WAI, etc.

- Accessibility is too important to go utterly un-mentioned in
this document and will be addressed in Section 3 which discusses
the wider context in which this document is to be used.
</section>

<section>
<title>Disagreement on Implementation</title>

On the other hand, the WAI CG does not agree that the language
as included in the April 28 draft implements these principles
successfully.  We have offered some edits below that would
enable us to concur that the new language implements the
agreement in principle and that the document should proceed
to PR.
</section>
</summary>

<change
class="clarity">

<quote
class="changeFrom"
cite="http://www.w3.org/TR/2005/WD-qaframe-spec-20050428/#scope-goals">
This document is a guide for W3C specification editors and authors.
It provides guidelines for writing better specifications.
</quote>

<draft
class="changeTo">
This document identifies practices to be followed in writing W3C
specifications which serve to make conformance to those
specifications crisp and clear.
</draft>

<rationale>

The existing language is true on the scope of the document and true
beyond the scope of the document. It is not scoping. The proposed
alternate language describes the extent of the topic actually covered
in this document.

The double-negative that almost backs into a scope statement in the
final paragraph of this section does not suffice as a positive
statement of the scope of this document.

To wit:

<quote
cite="http://www.w3.org/TR/2005/WD-qaframe-spec-20050428/#scope-goals">
In addition to conformance, there are several other topics that
should be addressed when writing a specification, such as
accessibility, internationalization, security, and device
independence. These topics are not directly in the scope of this
document, but are...
</quote>

</rationale>

<note
class="grammar">

The proposed language uses the pronoun 'which' in a restrictive
sense. This is British usage, and violates American usage. If the
intent is to base W3C specifications on American usage, the 'which'
should be replaced by 'that' so as to preserve the restrictive
quality of the clause.

</note>

<quote
class="changeFrom">

Beyond the way Working Groups define the conformance model of their
technologies, they should also take into account many important
considerations that will profoundly affect usage of the technologies.
Among them, accessibility, internationalization and device
independence are currently supported by W3C Activities and should
have a particular focus from other Working Groups.

Workings Groups need to design their technologies with accessibility
in mind, esp. if they define technologies used in User Interactions
context (e.g. HTML, SVG). Addressing accessibility in a specification
increases the likelihood that the defined technology can be accessed
by everyone regardless of disability. Otherwise, it may take several
revisions before software addresses accessibility features, leaving
people with disabilities behind.

For accessibility of XML-based vocabularies defined in a
specification, refer to the XML Accessibility Guidelines [XAG]. For
other information about specification accessibility, refer to the W3C
Web Accessibility Initiative (WAI).

</quote>

<draft
class="changeTo">

First and foremost, W3C specifications need to frame and define
technologies that meet the requirements of the particular
deliverable, fulfill the charter of the Working Group, and advance
the Mission of the Consortium.

The Mission of the Consortium involves extending the exchange of
information through the Web to everyone. Thus the requirements of
Accessibility, Internationalization and Device Independence are
general requirements that must be considered in the specification of
all Web technologies.

The Web Accessibility Initiative (WAI) is a Domain of the Consortium.
The WAI develops resources that assist all Web stakeholders to
contribute to and benefit from the accessibility of the web.
Specification developers should consult the Technical Reports Page
for an up-to-date profile of W3C publications in all areas. In
addition, they will find the WAI Home Page a helpful guide or
starting point with a focus on accessibility.

To date the Consortium has produced several Recommendations dealing
with Accessibility. The Web Content Accessibility Guidelines [WCAG10]
identifies requirements for information transiting the web. The User
Agent Accessibility Guidelines [UAAG10] identifies requirements for
software that users use to extract information from the Web. The
Authoring Tool Accessibility Guidelines [ATAG10] identifies
requirements for software that authors use to publish information to
the web.

For some further suggestions on how User Interface formats can
support these requirements, authors may wish to consult the Working
Draft "XML Accessibility Guidelines" [XAG].

</draft>

<note class="linking">
  In the above the abbreviations WCAG10, UAAG10, ATAG10, XAG are
hyperlinked, and in addition the phrases "Technical Reports Page" and
"WAI Home Page."
</note>

</change>


>Original Comment (Issue 1087 [1]):
>http://lists.w3.org/Archives/Public/www-qa/2005Feb/0005.html
>
>As a response to your comment, the QA Working Group has partially 
>accepted your
>comment.
>
>The QA Working Group agrees with the request of the WAI CG that SpecGL
>  should mention the need to consider accessibility while writing a
>specification, but disagree with making this a normative requirement
>  in SpecGL, since its scope in this version of the document is mainly
>focused on conformance related items and that QA WG participants don't
>  have enough background and experience to add further requirements on
>  this topic at this stage of development. In addition to accessibility,
>the QA Working Group has decided that SpecGL should mention the need to
>  additionally consider internationalization and device independence while
>  writing a specification. Accordingly, a new Section 3.3 (Accessibility,
>  Internationalization, and Device Independence Considerations) has been
>  created in the revised SpecGL draft [2]. Note that there is a reference to
>  the XML Accessibility Guidelines within Section 3.3.
>
>[0] http://www.w3.org/TR/2004/WD-qaframe-spec-20041122/
>[1]: http://www.w3.org/Bugs/Public/show_bug.cgi?id=1087
>[2]: http://www.w3.org/TR/2005/WD-qaframe-spec-20050428/#address-other-topics
>
>--
>Karl Dubost
>QA Working Group Chair
>http://www.w3.org/QA/WG/
Received on Wednesday, 25 May 2005 22:17:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:36 UTC