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

Comments on Authoring Tools Guidelines

From: John Slatin <jslatin@mail.utexas.edu>
Date: Mon, 4 Oct 1999 08:57:58 -0500
To: <w3c-wai-au@w3.org>
Message-ID: <001b01bf0e70$77dd96c0$f14a7481@ital.utexas.edu>
On the whole, the Authoring Tools Guidelines document seems comprehensive
and well thought out; tools designed in accordance with the guidelines are
likely to help Web authors produce more accessible content, assuming that
they want to do so.

The Techniques document is also comprehensive and thorough.  But there is
also an inadvertent  bias toward the visual without a corresponding emphasis
on non-visual equivalents for key visual features.  For example, there are
frequent references to "highlight," as in the suggestion that accessibility
errors be highlighted on the screen in the way that, e.g., MS Word
highlights misspelled or repeated words.  This is fine-but Word uses a
subtle visual cue (a faint, squiggly underline in red) that is so
unobtrusive it's difficult to see, and there is no auditory equivalent.  I
realize that this may be a JAWS issue rather than a Word issue; however, I
would like to have a Web authoring tool that inserted an audio index tone to
signal the presene of a problem.  That way, a screen reader program could
beep or chime discreetly while reading a line; different tones would
indicate different types of problems. If the list were relatively short,
users would be able to learn the tone-indexing pretty quickly.  This could
be a configurable option in the tool itself, or perhaps it would be turned
on or off according to the way the individual user had set the Accessibility
Options in the Windows or Mac control panels.  It should also be possible to
get a quick list of all these errors, e.g., in a scrollable list.  I'm
thinking of something like the lists that IE gives you, or the "Jumps and
Links on this page" list in WebSpeak, or the list of structural items that
Home Page Reader reads in a different voice from the one that goes through
the text.  Such a list would provide yet another way of navigating through
the document without changing what's published.  The guidelines propose
allowing authors to navigate their evolving documents by following
structural markup; why not also navigate it by accessibility problems or
problem areas, e.g., look at all FRAMESETS and in each one navigate
according to checklist priorities 1, 2, and 3?  Presumably sighted, hearing,
etc., authors would also find such a tool useful since it would help them
find and fix problems more quickly.

On another front, I'd like to suggest more attention to document preview.
Most Web authoring tools available now allow authors to preview their
documents in, e.g., IE or Netscape.  I'd like to propose that the preview
function also include an audio preview-i.e., allow authors to hear what
their pages sound like to users coming in with speech-based browsers.  I've
found that this is always a kind of revelation to designers, and helps them
grasp why it's important to do things like provide a "Skip Navigation" link,
for example, or do a better job with the ALT text for an image map.

John Slatin, Director
Institute for Technology & Learning
FAC 248, Mailcode G9600
University of Texas at Austin
Austin, TX 78712
Phone 512-495-4288, fax 512-495-4524
Email jslatin@mail.utexas.edu
Web http://www.ital.utexas.edu
Received on Monday, 4 October 1999 09:56:23 UTC

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