- 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 UTC