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

Re: Proposal re: AI-20050411-1

From: Dominique HazaŽl-Massieux <dom@w3.org>
Date: Fri, 15 Apr 2005 10:51:13 +0200
To: Tim Boland <frederick.boland@nist.gov>
Cc: www-qa-wg@w3.org
Message-Id: <1113555073.3928.239.camel@stratustier>
Hi Tim,

Le jeudi 14 avril 2005 ŗ 08:37 -0400, Tim Boland a ťcrit :
> My text (a new (sub)section 3.3 for the "Beyond Conformance" section 
> of "Editor's Version" of SpecGL) is following.

Thanks for starting this! I think the content is pretty good generally
speaking; the main comment I have on it is that it doesn't distinguish
clearly what is about the specification itself (i.e. the document
produced by a WG) and the technology defined in the specification. I've
inserted a few proposed rewrites below - I've also tried to apply some
of stylistic principles that Richard has worked on applying to the rest
of SpecGL (esp. with regard to using passive sentences); let me know you
what you think.

> --------------------------------------------------------------
>  
> "3.3 Address Accessibility, Internationalization, and Device
> Independence
> 
> Accessibility of a specification must be encouraged by the Working
> Group, so 
> that a specification is available to anyone. 

-> 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).

> The benefit of 
> addressing accessibility in a specification is the increased
> likelihood 
> that a specification can be accessed by everyone regardless of
> disability. 

Addressing accessibility in a specification increases the likelihood
that the defined technology can be accessed by everyone regardless of
disability.

> The Working Group should designate an individual 
> to monitor accessibility of a specification at the earliest possible
> point 
> of specification development, so that classes of products 
> defined in a specification will implement the accessibility features
> of 
> a specification from the beginning.

Maybe this advice that applies to all 3 categories could be factorized
at the end of this subsection, to avoid the redundancy?
(maybe this would the right point to mention contacting the relevant
Working Groups to get help on this topic?)

>  Otherwise, it make take several 

"make take" -> "may take"

> revisions before software addresses accessibility features, leaving 
> people with disabilities behind.

I suggest removing the following block, as somewhat redundant (and to
try to keep the section short):
>  Furthermore, when the review of 
> support of a specification for accessibility occurs, accessibility 
> will be adequately addressed in a specification. Formalizing the
> position of the 
> Working Group on accessibility by a clearly defined section and prose
> in a specification 
> removes ambiguities for specification users about the possibility 
> of addressing accessibility.


>  For accessibility of XML-based vocabularies 
> defined in a specification, refer to the XML Accessibility
> Guidelines[1]. 
> For other information about specification accessibility, refer to the 
> W3C Web Accessibility Initiative (WAI) 
> [2].
>
> 
> Similarly, the Working Group should support "internationalization" of
> a specification to the maximum extent possible and appropriate. 

-> Similarly, the Working Group should make sure the defined technology
is compatible with internationalization, i.e. is not specific to a
particular language or culture.

> The benefit of addressing "internationalization" in a specification is

replace ["internationalization"] with [internationalization questions]

>  to ensure that the formats and protocols defined in a specification
> do not create barriers for languages, writing systems, character
> codes, and other local conventions employed by specification users.

... employed by end users ("specification" users is ambigous: are they
the people reading the spec, or the people using the implementations
conforming to the spec? I think in this case we mean the latter)

>  The Working Group should designate an individual 
> to monitor "internationalization" of a specification at the earliest
> possible point 
> of specification development, so that classes of products defined in a
> specification will implement the "internationalization" features of a
> specification from the beginning, and so that when the review of
> support of a specification for "internationalization" occurs,
> "internationalization" 
> will be adequately addressed in a specification.

(see above wrt factorizing these)

I suggest dropping the paragraph below:
>  Formalizing the position of the 
> Working Group on "interationalization" by a clearly defined section
> and 
> prose removes ambiguities for specification users about the
> possibility of addressing 
> "internationalization".


>  For information on interoperable text manipulation for text 
> defined in a specification, refer to the Character Model for the World
> Wide Web[3]. For other information about specification
> "internationalization", refer to the W3C Internationalization (I18N) 
> Activity[4].
> 
> 
> Finally, a specification of a Working Group should support device 
> independence to the maximum extent possible and appropriate, to
> provide 
> diversity of interaction with a specification by people. 

"with a specification" -> "with a technology"

> The benefit of 
> addressing device independence in a specification is the increased 
> likelihood that a specification can be accessed from any device, 
> in any context by anyone. 

(see above for the paragraph below)
> The Working Group should designate an individual 
> to monitor device independence of a specification, so that 
> classes of products defined in a specification 
> will implement the device independence features of 
> a specification from the beginning


(suggest dropping paragraph below)
> , and so that when the review of 
> support of a specification for device independence occurs, device
> independence 
> will be adequately addressed in a specification. Formalizing the
> position of the 
> Working Group by a clearly defined section and prose removes
> ambiguities 
> for specification users about the possibility of addressing 
> device independence.


>  For information about 
> specification device independence, refer to the W3C Device
> Independence Summary [5].

To summarize, here is how my proposed rewrite would look like:
--------------------------------
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[1]. For other information
about specification accessibility, refer to the W3C Web Accessibility
Initiative (WAI) [2].

Similarly, the Working Group should make sure the defined technology is
compatible with internationalization, i.e. is not specific to a
particular language or culture. The benefit of addressing
internationalization aspects in a specification is to ensure that the
defined formats and protocols do not create barriers for languages,
writing systems, character codes, and other local conventions employed
by end users of the technology.

For information on interoperable text manipulation for text defined in a
specification, refer to the Character Model for the World Wide Web[3].
For other information about specification "internationalization", refer
to the W3C Internationalization (I18N) Activity[4].

Finally, a specification of a Working Group should support device
independence to the maximum extent possible and appropriate, to provide
diversity of interaction with a technology by people. The benefit of
addressing device independence in a specification is the increased
likelihood that a specification can be accessed from any device, in any
context by anyone. 

For information about specification device independence, refer to the
W3C Device Independence Summary [5].

For each of these considerations, a Working Group should consider
designating a participant to monitor their applications to the
specification at the earliest point possible and to be the point of
contact with the relevant W3C Working Groups to seek feedback on the
adopted solutions.

Resources:
[1]: http://www.w3.org/TR/XAG 
[2]: http://www.w3.org/WAI/ 
[3]: http://www.w3.org/TR/charmod/ 
[4]: http://www.w3.org/International/ 
[5]: http://www.w3.org/2001/di/
----------------------------------------------------

Dom
-- 
Dominique HazaŽl-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org


Received on Friday, 15 April 2005 08:51:17 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Thursday, 9 June 2005 12:13:20 GMT