W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 1999

Re: "make the tool accessible"

From: Kynn Bartlett <kynn-hwg@idyllmtn.com>
Date: Wed, 19 May 1999 11:03:28 -0700
Message-Id: <>
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
Received on Wednesday, 19 May 1999 14:36:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC