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

Last Call Comment (Documentation)

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Mon, 04 Oct 1999 11:48:15 -0400
Message-Id: <4.1.19991004110230.009e7a40@pop3.concentric.net>
To: Authoring Tools Guidelines List <w3c-wai-au@w3.org>
Aloha, y'all!

After concluding my conformance evaluation of HomeSite 4.0.1, I have come
to the conclusion that there is one glaring omission from the Authoring
Tool Guidelines document:  namely, that the accessibility of the help and
documentation needs to be explicitly addressed in the Guidelines and not
merely mentioned in the Techniques.

Justification:
1. GL6 "Promote accessibility in help and documentation" is meaningless for
a person with a disability who is attempting to use the authoring tool's
Help system if the help system is not itself accessible.  While this is
covered in a general manner in GL7 "Ensure that the Authoring Tool is
Accessible to Authors with Disabilities", I believe that a more explicit
statement which addresses the necessity of ensuring that the online/runtime
help system is accessible to persons with disabilities MUST be added to GL7.

Example:
1. Allaire's HomeSite 4.0.1 provides a list of keyboard shortcuts in PDF
format only. Because the keyboard shortcuts are listed in the PDF file in a
table, when they are converted to plain text, the output is less then
clear.  A brief example of the converted list of keyboard shortcuts follows:

quote
File > Open Ctrl + O File > Save Ctrl + S File > Save As Shift + Ctrl + S
File > Close Ctrl + W File > Close All Shift + Ctrl + W File > Print Ctrl +
P Open default template CTRL + N Insert Code Template text/ open list Ctrl
+ J Edit > Undo Ctrl + Z Edit > Redo Shift + Ctrl + Z Edit > Repeat Last
Tag Ctrl + Q Edit > Cut Ctrl + X Edit > Copy Ctrl + C Edit > Paste Ctrl + V
Edit > Select All Ctrl + A Edit > Indent Shift + Ctrl + . (period) Edit >
Unindent Shift + Ctrl + , (comma) Edit > Toggle Bookmark Ctrl + K Edit >
Goto Next Bookmark Shift + Ctrl + K Edit > Goto line Ctrl + G Goto previous
document Shift + Ctrl + Tab Goto next document Ctrl + Tab Goto next start
tag Ctrl + ] (right bracket) Goto previous start tag Ctrl + [ (left
bracket) Delete line Ctrl + Y Delete string Ctrl + Del Delete previous
string Ctrl + Backspace 
unquote

Not completely incomprehensible, but clearly a major inconvenience for
anyone attempting to use this help file using speech.

2. While the mechanism for invoking the online/runtime help provided with
HomeSite 4.0.1 is in the Windows Help format, one cannot use the keyboard
to navigate the Help tree, indicating that not all of the conventions that
supposedly govern the use of the Windows help format have been implemented.
 I was, for example, unable to move through the Help tree using the arrow
keys, and was forced to use JFW's mouse emulation keys to open individual
help topics and then move the point of regard to the content for that
topic, which is contained in a parallel child window, as the content of the
Help window is not voiced by JFW when it is painted to the screen, nor is
the point of regard shifted to the Help file when it is opened.

3. I subsequently discovered that HomeSite's Help system is a hybrid: while
the Help Resource Tree (apparently) utilizes the Windows Help format, the
actual content of most of the Help files is marked-up using HTML. This is
not, however, self-evident from the design of the Help system, nor can it
be intuited by anyone working in an eyes-free environment, as the clickable
button which allows one to open the Help window in an external browser was
not recognized by JFW, and, hence, not spoken.  Only when I manually
explored the screen using the speech cursor with JFW set to report all
graphics (the other choices are "none" and "labeled", i.e. those for which
a label has been pre-defined by either the manufacturer or the user) did I
discover the presence of these buttons, which were reported as "Graphic
XXX", Graphic YYY", and Graphic "ZZZ" (where XXX, YYY, and ZZZ represent
the numbers arbitrarily assigned to the graphic by JFW). For a blind user,
such as myself, the use of such gross navigational tactics is analogous to
navigating an abandoned Grand Central Station without a sighted guide or
white cane, for the only things that I learned from this gross navigational
method was: (a) if I could figure out how to get the information that is
used to generate the ToolTip passed to JFW, I'd have a job at Henter-Joyce,
and (b) that there were a number of graphical buttons in the active portion
of the screen (to which the JFW cursor had been restricted). Obviously, the
only way for me to find out what actions the buttons perform was to
simulate a right mouse click and pray that context sensitive help was
available for that button. Unfortunately, my prayers weren't answered, so
the next course of action was to simulate a left mouse click on each
button, and pray that whatever action or event the activation of the button
invoked would be voiced by JFW. A highly unscientific -- not to mention
downright maddening -- means of discovering what could have been made
self-evident if only HomeSite had a "Display Buttons As Text Only" option,
such as that offered by Opera.  I attempted to use a workaround which I
have used to label graphics that are used on the toolbars in Microsoft's
Office family of products without sighted assistance.  This method involves
opening the "Customize" property sheet for the toolbar. In most MS Office
applications, the toolbar icons are displayed in a list box, alongside a
textual equivalent, so simply setting JFW to read "all graphics" allows me
to place the mouse cursor on the icon, use JFW's "speak from cursor"
command to hear the textual label for the icon, and then, by invoking JFW's
Graphics Labeler, to label the graphic.  Due to the design of HomeSite's
"Customize" property sheet, however, this workaround (time-consuming as it
is) was not feasible.

4. While the images used for the "Back", "Up Level", and "Next" buttons in
the Help files are ALT-texted, there are numerous graphics, such as the
annotated screen shot that explains the layout of the main workspace areas,
which are  not ALT-texted.  Moreover, in the example of the annotated
screen shot, there is no textual equivalent for the information conveyed by
that graphic.  While a LONGDESC could theoretically be used, since LONGDESC
isn't currently supported by GUI UAs, a textual link, leading to a textual
description of the main workspace areas would be the optimal solution.

--- end of Last Call Comment on Documentation
--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------
Received on Monday, 4 October 1999 11:42:36 UTC

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