- From: Kynn Bartlett <kynn-hwg@idyllmtn.com>
- Date: Wed, 19 May 1999 11:03:28 -0700
- To: pjenkins@us.ibm.com
- Cc: Charles McCathieNevile <charles@w3.org>, w3c-wai-au@w3.org
At 12:09 PM 5/19/1999 -0500, pjenkins@us.ibm.com wrote: >In fact, as many of you know from WWW8 meetings, I'm concerned with the >inclusion at all of a checkpoint on making the tool accessible because "software >accessibility" is covered in many other places. How many of the authoring tools that exist now are accessible to users with disabilities? Your argument would hold more water if, say, Gregory [sorry to always use you as the canonical example, dude :)] could pull any web authoring software off the shelf and use it as effectively as I could. But (to the best of my understanding) that doesn't happen now; there is a need that must be addressed. Remember that we are not just writing this for Phill and Bruce; most software companies out there DON'T have a solid set of guidelines like IBM/Lotus does, or if they do, they don't follow it with as much care or commitment. >I also believe a developer >[since I are one] will be more concerned first with the functions and features >he or she needs to add. The logical retort to this is "accessibility of the tool is a function and/or feature that needs to be added", you realize. :) >Making those features accessible is just as important >as the other things he or she needs to be concerned with; "abilities" of the >features and functions like translation, documentation, usability, >compatibility, accessibility, etc. I encourage the working group to keep the >checkpoint on "make the tool accessible" at the end of the list. I still don't see what it accomplishes other than to give the idea that it's a "footnote" to the rest. Your example of 3.2.3 (or whatever number it was; too lazy to look it up) _highlights_ this point. It says "make the properties of the elements accessible to the author." Which is a good thing for _all_ authors and not just for authors with disabilities. However, in that language there's an unstated assumption that "accessible" also includes "accessible in an accessible way"; in other words, this rule says both to make the information available, and to do it in a manner that can be used by people with disabilities. If you move the "MTTA" guideline to the start, then it is more clear when reading something such as the above that both meaning are meant; serving as a preface to the whole process, it impresses upon you early on that this MTTA guideline is a blanket over the whole document. If you put it at the end, you lose that, and thus you'll need to explicitly state such clumsy construction as "make the elements accessible in an accessible way", because the author won't be able to apply the MTTA concept to everything else they read. At best, you're asking them to go back and re-read everything from the start when they hit MTTA; at worst you're inviting them to consider it last and thus a low priority. For these reasons I think it's obvious that the MTTA guideline MUST go first. I'd argue that "integrate naturally" would go second if anyone wanted to debate me on that one. :) -- Kynn Bartlett <kynn@hwg.org> President, Governing Board Member HTML Writers Guild <URL:http://www.hwg.org> Director, Accessible Web Authoring Resources and Education Center <URL:http://aware.hwg.org/>
Received on Wednesday, 19 May 1999 14:36:42 UTC