- From: Roberto Scano - IWA/HWG <rscano@iwa-italy.org>
- Date: Sun, 7 May 2006 22:28:35 +0200
- To: "'Jan Richards'" <jan.richards@utoronto.ca>, <w3c-wai-au@w3.org>
---------- IN GUIDELINES: http://www.w3.org/WAI/AU/2006/WD-ATAG20-20060322/WD-ATAG20-20060322.html#che ck-tool-document "Document the authoring interface including all interface accessibility features. [Priority 1]" I think that the actual guideline clearly describe the requirements for the authoring tools producers. ---------- RATIONALE: "Rationale: While intuitive authoring interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, an author who is blind may not find a graphical authoring interface intuitive without supporting documentation." I suggest an integration for the rationale: "Rationale: While intuitive authoring interface design is valuable to many authors, some authors may still not be able to understand or be able to operate the authoring interface without thorough documentation. For instance, an author who is blind may not understand a graphical authoring interface or an user may not understand or find commands or functionality inside the authoring interface without supporting documentation." ---------- SUCCESS CRITERIA: "1. At least one version of the documentation must conform to the minimum requirements (Level 1) of WCAG (whether delivered on the Web, CD-ROM, etc.)." I suggest to remove the (whether delivered on the Web, CD-ROM, etc.) due that must be clear that *all* digital version of documentation should conform. So a possible rewording could be: "1. At least one version of the documentation must conform to the minimum requirements (Level 1) of WCAG (whether delivered in digital version)." "2. All features that benefit the accessibility of the authoring interface must be documented in the help system (e.g., keyboard shortcuts)." For conformance, i suggest to change "help system" with "documentation". "2. All features that benefit the accessibility of the authoring interface must be documented in the documentation (e.g., keyboard shortcuts)." "3. The current configuration of selectable actions must be displayed in either a centralized fashion (e.g., a list of keyboard shortcuts) or a distributed fashion (e.g., by listing keyboard shortcuts in the user interface menus). " This success criteria sounds good. ---------- TECHNIQUES: http://www.w3.org/WAI/AU/2006/techs/tech1.html#check-tool-document Technique A.3.3-1.1 [Sufficient]: propose little rewording Providing a complete version of the documentation (on the Web or bundled on the CD-ROM) as Web content that conforms to WCAG Level A. Also for the SC, remove the (on the Web or bounbled on the CD-ROM). Technique A.3.3-2.1 [Sufficient]: ok Documenting all aspects of the user interface covered by Part A of these guidelines (including keyboard accessibility, display configurability, etc.). Technique A.3.3-2.2 [Advisory]: ok Providing a documentation index to accessibility features. Technique A.3.3-3.1 [Sufficient]: correct mistyping (double )) Displaying the current configuration of accessibility features (i.e. keyboard shortcuts, visual display (if applicable), auditory display (if applicable)) either centrally or in a distributed fashion. Technique A.3.3-0.1 [Advisory]: ok Making context sensitive help and other forms of support accessible, in addition to the larger help pages. Technique A.3.3-0.2 [Advisory]: ok Providing installation codes in accessible electronic format, not just in the paper documentation or printed on the installation media. Cheers. Roberto Scano IWA/HWG
Received on Sunday, 7 May 2006 20:28:58 UTC