product documentation

Thanks to Mark, Charles and David for their comments regarding checkpoint
4.1.2, accessible  documentation. I'd like to add some comments. This
morning I conferred with four of my colleagues who use screen readers and
who also answer many technology related questions posed by other, less
experienced, assistive technology users.  Of course I got four different
responses, but I am able to look at the problem in a slightly different

1. My colleagues and I agree that there are other checkpoints that should
be given a "higher priority" than accessible documentation, at least in
terms of order of implementation. That is, if we had to choose between full
keyboard navigation and accessible documentation, we'd pick keyboard

2. However, I don't think we should use the argument that implementing
features, in general, is more important than providing accessible
documentation. There are specific features that are more important than
documentation, but looking over the list of priority 1's, I would rank
accessible documentation above some of them. In fact, I would be interested
in having people rank order all of the priority 1s. I wonder which would
rise to the top of the list when we compared rankings. 

3. If the other priority 1 items in this document are implemented, the user
will have a great deal of flexibility in terms of configuring the
application to best suit his or her needs. And as David pointed out, for
individuals without access to assistance, access to documentation might be
the only recourse. 

As a point of illustration, I asked 13 screen reader users to turn off
images in Netscape 4.05 (as part of a research study). For a number of
reasons, no one succeeded in turning off images.  And the four users who
ventured into the help system to figure out how to turn off images were
totally stymied by Netscape's inaccessible help system. So we have to be
careful about building in configuration capability and then hiding it some
place where users can't find it.  Ideally, the user interface would be so
accessible and usable that documentation is not even needed, but if we are
going to expect users to configure the user agent then the documentation
must be accessible.

4. In terms of documentation format, I don't think it is unreasonable to
expect the user to use the browser to learn about the browser. At least in
terms of desktop graphical browsers, if the user agent follows certain
platform conventions (e.g. menus) and the help system is accessible, the
built in help should guide the user.

Is sum, I would vote for making 4.1.2 a priority 1. I think we could safely
argue that some users will not be able to independently configure the user
agent to be accessible without access to the documentation. 

Just my 2 cents,


Received on Friday, 26 February 1999 13:52:39 UTC