- From: Judy Brewer <jbrewer@w3.org>
- Date: Thu, 08 Oct 1998 23:52:12 -0400
- To: "Jan Richards" <jan.richards@utoronto.ca>, <w3c-wai-au@w3.org>, jutta.treviranus@utoronto.ca, ij@w3.org
Authoring Tool Guidelines WG: Good to see the new AU guidelines working draft. I encourage other AUWG members to take the time to go through this draft and comment to the list as soon as possible, as well as to discuss the draft on the phone meeting that Jutta has arranged for the 13th. We need to move this forward, and need your help to do so. My comments follow. Regards, Judy Generally: 1. The document outline is a great improvement over previous drafts and more comprehensively addresses the issues. 2. The format is inconsistent from item to item in the document: there is a mix of guideline, rationale, and technique for each item, sometimes in different order. To be consistent with the evolving WAI guidelines format, use: broad categories; and within those, simple guideline statements, followed by a brief rationale, followed by available techniques to implement that guideline; leaving technical details of implementation to appendices. The best example of this format presently is the WAI Page Author Guidelines Working Draft at http://www.w3.org/TR/WD-WAI-PAGEAUTH. Examples of problem areas in the current AU draft, where there is not a clear guideline/rationale/technique statement: 3.B.4 rationale is too long, and there is no technique or example 3.C.1 there's a guideline, a restatement of that guideline, some rationale, then more guideline 3.C.2 a definition (which should be covered in the definition section up front), more definition, then two very different guidelines, the second of which is a critical issue that should not be buried. 3. The guidelines themselves should be as directly stated as possible. Use the active voice (actually, the imperative -- start each guideline with a verb), which has more impact, and is easier to understand and translate than passive voice (see 3.C.4). For instance, replace: "3.A.3 All inaccessible markup must be exposed" with: "3.A.# Expose all inaccessible markup" and replace: "3.B.3 Help examples should include accessibility solutions" with: "3.B.3 Include help examples in accessibility solutions" 4. Keep the tone objective. There are some sections that sound like opinion rather than guidelines (3.A.5 "If proper integration is neglected... authors will be likely to treat the recommendations with equally little regard" and some sections that sound negative (3.A.5 "When a new feature is added... in a careless way" or special note at 3.C "boring, repetitive..."). It's possible to convey the same information in a more objective way: "Integration of an accessibility-related feature into the pre-existing user interface increases user acceptance." 5. Eliminate use of "Special Notes": if these are in fact valid and necessary pieces of information, just make them part of the introduction to a section. 6. Several of the guideline items seem to actually be several items rolled into one. For instance, 3.A.4 includes recommendations for accessibility-checking strategies in site management tools, alerts for alt text in image editors, and encouragement for descriptive text in video editors. 7. Use "Web" instead of "WWW" to be consistent with W3C style. 8. I recommend "Universal Design" over "Universal Access" since the latter occassionally gets confused with the "Universal Service" concept in telecommunications. But perhaps this issue has already been discussed by the WG. 9. The title of the core of the document seems odd. Why is it called "Guidelines for Accessible Document Production" (sounds like the page author guidelines) rather than "Guidelines for Development of Web Authoring Tools that Support Accessibility" or something like that? 10. For the note at the beginning of the document, wouldn't it be clearer to say "This document provides guidance on the development of Web authoring tools which produce accessible Web pages, consistent with the 'WAI Page Authoring Guidelines.'" 11. At 2.1, Markup Authoring, Conversion and Generation Tools, I don't understand the last paragraph which states that these guidelines don't address generation tools, but that the guidelines apply to generation tools. I recommend that these guidelines directly address generation tools as well as the other two. In addition, why not include site management tools, image-editors, video-editors, and multimedia authoring tools to the extent that those tools have accessibility-related issues for development of Web content? You already cover many of the issues in the guidelines you've written to date. 12. At 2.5, add "or structured tree view" to the examples of different views (such as the Amaya authoring capabilities support) 13. At 2.7, is it necessary to define these two items? 14. At 3.A.1, this isn't just related to the page author guidelines; I think you also need to include a list of all the accessibility-related features in HTML4, CSS2, SMIL, etc. since the page author guidelines includes multiple and sometimes alternate techniques for guideline items. These can be pulled out of the /WAI/References/html4-access & /css2-access, or Ian may be working on a listing. If we don't list the items to implement, we shouldn't expect the engineers who're developing code to take more trouble than we have to find the items & make sure they understand the purpose & issues involved in implementing them. 15. At 3.A.2, what's the difference between the first and the third bullet? 16. At 3.A.4, what is a "serious, effective, and uniform manner"? I'm not sure that an authoring tool engineer would find that clear or helpful. 17. At 3.B.2, at "the justifications should also address", for the first item (aging) please add "hearing and cognitive" (actually, statistically in that age bracket I believe new hearing loss is greater than the others); and for the second item please add cognitive. (and what's the WAI Justifications Document? the business-case-to-be?) 18. 3.B.4 great! 19. 3.C.1 2nd P is scrambled; and this one needs an example or technique pointer. 20. 3.C.3 Critical point, but needs to be more clearly stated. 21. References: CSS1 - isn't there a non-date specific URL for this? should be. #end At 03:08 PM 9/29/98 -0400, Jan Richards wrote: >Hi all, > >A new draft guideline has been placed on the the site: >http://www.w3.org/WAI/AU/ > >Please send any comments, revisions, etc. to the list. > >Jan Richards >ATRC >jan.richards@utoronto.ca > > ---------- Judy Brewer jbrewer@w3.org +1.617.258.9741 http://www.w3.org/WAI Director, Web Accessibility Initiative (WAI) International Program Office World Wide Web Consortium (W3C) MIT/LCS Room NE3-355, 545 Technology Square, Cambridge, MA, 02139, USA
Received on Friday, 9 October 1998 00:15:05 UTC