W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 1999

draft documentation techniques

From: Kitch Barnicle <kitch@afb.org>
Date: Wed, 03 Mar 1999 09:11:13 -0500
Message-Id: <Version.32.19990301080741.00f42110@pop.igc.org>
Message-Id: <Version.32.19990301080741.00f42110@pop.igc.org>
Message-Id: <Version.32.19990301080741.00f42110@pop.igc.org>
Message-Id: <Version.32.19990301080741.00f42110@pop.igc.org>
Message-Id: <Version.32.19990301080741.00f42110@pop.igc.org>
Message-Id: <Version.32.19990301080741.00f42110@pop.igc.org>
To: w3c-wai-ua@w3.org
Hi Folks,

I've created very rough draft of techniques for checkpoints 4.1.2 and
4.1.3. I wanted to send it out to see if I am on the right track. So please
comment freely. I do think we need to define what we mean by documentation.
Some of my colleagues have suggested that documentation refers only to
"user manuals" and others have suggested that documentation includes
"everything that gives the user instructions" including manuals, the help
system, tooltips, and context sensitive help. As I said in an earlier
message, I had been considering help systems as part of the documentation
but then the issue of content versus interface comes up. I'm sorry if I
seem to be making this more complicated than it should be.

-Kitch 


Documentation - 


Checkpoint 4.1.2 [Priority 2] 
Ensure that product documentation is available in at least one accessible,
open standard electronic format (e.g., HTML, XML, ASCII). 

1. Electronic documentation

Electronic documentation created in open standard formats such as HTML and
ASCII can often be accessed in the user's choice of application such as a
word processor or browser. Accessing documentation in familiar application
could be especially important to users with disabilities who must first
configure a user agent to meet their needs or configure a user agent to be
compatible with assistive technology. Electronic documentation should NOT
be provided in proprietary formats such as PDF.


Documentation created in HTML should follow the <link>Web Content
Accessibility Guidelines </link>

[How much detail should we include regarding content structure eg. describe
figures, avoid columns etc?]


2. Alternative Formats

Users with print impairments may need or desire documentation in
alternative formats such as Braille, large print, or audio tape. User agent
manufacturers should provide user manuals in alternative formats upon
request. Documents in alternative format documents can be created by
agencies such as Recording for the Blind and Dyslexic (www.rfbd.org) and
the National Braille Press (www.nbp.org). [Can we refer to specific
agencies? What about international agencies?]


3. Text of documentation

User instructions should be created in an input device-independent manner.
Provide instructions for using or configuring the user agent in a manner
that can be understood by a user of any input device including a mouse or
keyboard. For example, "Click on the Home button on the toolbar or select
"Home" from the Go menu to return to the Home page. "


Checkpoint 4.1.3 [Priority 2] 
Describe product features known to promote accessibility in a section of
the product documentation.

1. Index
Include terms related to product accessibility in the documentation index
(e.g. accessibility, disability/disabilities)

2. Table of Contents
Include terms related to product accessibility in the documentation table
of contents (e.g. Features that promote accessibility)

3. Include instructions on how to modify all user configurable defaults and
preferences. 
(e.g images, video, style sheets, and scripts) [Should we list every user
configurable feature?]

4. Include a list of all keyboard shortcuts in the accessibility section of
the documentation. 


Maybe some of the product developers on this list can offer additional
suggestions.
Received on Wednesday, 3 March 1999 09:13:08 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:22 UTC