- From: Jaustral <jaustral@yahoo.es>
- Date: Thu, 11 Sep 2003 00:44:05 +0200
- To: public-comments-wcag20@w3.org
SIDAR (Seminario Iberoamericano sobre Discapacidad y Accesibilidad en la Red) is a permanent working group devoted to promote accesibility in new technologies and web accesibility as its core concern. Its members are volunteers from all over Latin America, Portugal and Spain are experts in IT and accessibility. For an extensive introduction please visit www.sidar.org WCAG2-espa is a Spanish translation group focused on WCAG 2.0, formed when the first working draft was released. We would like to thank the opportunity the Working Group is offering the web community requesting comments on their work. Comments on 06/24/2003 Working Draft of WCAG 2.0: Comments are organized as follows. First, the part of the text commented is written, according to the hierarchy expressed in the table of contents. Then a link to the nearest anchor in the document is given, and finally the comment to the point is explained. Highlighting is made placing text in asterisks. 1)Introduction: How to read this document: Technology-specific checklists URL: http://www.w3.org/TR/2003/WD-WCAG20-20030624/#how-to We'd like to congratulate the working group for approaching the new version of the guidelines in this way, separating the different layers that are present in web content production processes. The first one involves design and is the main concern of these guidelines. The document acquires a more abstract point of view and detaches from the final technology used by the user to access the content. However, this more abstract approach moves the guidelines away from their final application in web content production. This is the main reason why we think that the second group of documents, the Technology-specific Checklists, must strengthen the purpose of the guidelines and therefore should be normative for each technology. That is to say, conformance to these guidelines and conformance to technology-specific checklists should be bound in a clear and plain way. 2)Introduction: Conformance URL: http://www.w3.org/TR/2003/WD-WCAG20-20030624/#conformance With regard to the different levels of comformance, we think that considering a "Core+" level is a good idea. But we think that the wide spectrum and subtleties inside this qualification shouldn't be measured by the number of checkpoints that are met. A more satisfactory way to do it would be to create several combinations of Extended Checkpoints to qualify the specific way in which the content cares about accessibility. These combinations would give different "flavours" to "Core+" conformance claim. As an example, verification of Extended CheckPoints 1.5, 2.4, 3.4 could qualify "Core+" conformance claim as "usable" as it considers perception, operability and understandability points that strengthen usability of the content. 3)Guideline 1: Core Checkpoints: 1.1 URL: http://www.w3.org/TR/2003/WD-WCAG20-20030624/#text-equiv We think it's a basic conceptual error to use the expression "non-text content that can be expressed in words". What does it mean? All content *can* be expressed in words or described in some way. With all our respect it's like saying "oops sorry, I remained speachless" in the ALT attribute of an image. When one reads Required Success Criteria 2. of this checkpoint, one thinks you are talking about "non-text content that can not be expressed in *a few* words". So, shoudn't the Checkpoint read: "1.1 [CORE] All non-text content that can be expressed in a few words has a text equivalent of the function or information that the non-text content was intended to convey. [was 1.1]". And Required Success Criteria 2. should read: "non-text content that can not be expressed in a few words has a descriptive label provided as its text-equivalent" 4)Guideline 1: Core Checkpoints: 1.3: Example 4 URL: http://www.w3.org/TR/2003/WD-WCAG20-20030624/#content-structure-separation Example 4 in this checkpoint should also include a reference to checkpoint 4.3 5)Guideline 2: Core Checkpoints: 2.1: Definitions: Editorial Note URL: http://www.w3.org/TR/2003/WD-WCAG20-20030624/#keyboard-operation Proposed definition for "operable through a keyboard interface": Content is operable when it is properly designed in a way that all the information is reachable and all the funcionality is available through an efficient use of a keyboard interface. An appropriate hierarchical collection of keyboard shortcuts or a navigation bar situated after each section strengthens operability. Intensive use of tabbing weakens operability due to monotony and lack of a clear structure. 6)Guideline 2: Extended Checkpoints: 2.4 URL: http://www.w3.org/TR/2003/WD-WCAG20-20030624/#navigation-mechanisms Shouldn't this checkpoint be a Core one? Besides, we think the Required Success Criteria miss the point. We think there shouldn't exist a trigger length below which unstructured documents are happily welcome. Allowing structure markup to disappear is a step backwards, since even in a single document without a table of contents, structural markup such as lists, paragraphs, etc. give a solid base to understand the relative weight of different content pieces. The way the Checkpoint is written allows for weird interpretations such as thinking that alternate navigation mechanisms can substitute structure. We propose an alternate redaction for Checkpoint 2.4 : "The contents are structured and alternate navigation mechanisms have been added to facilitate orientation and movement within" Of course this implies a reformulation of the whole explanation of the Required Success Criteria. 7)Guideline 4: Extended Checkpoints: 4.3 URL: http://www.w3.org/TR/2003/WD-WCAG20-20030624/#technology-supports-access This a controversial Checkpoint becuase it involves the other layers of web content production processes. Maybe it should be reformulated but it shouldn't disappear. Maybe it could be the binding point with the Technology-specific Checklists. Developers and web designers, whatever the device they are thinking of primarily, must know that they must produce accessible products. See our comment to "How to read this document". Thanks again for this opportunity to contribute to WCAG 2.0. Juan Luis Lara WCAG2-espa coordinator
Received on Wednesday, 10 September 2003 18:48:58 UTC