revised documentation techniques

A revised version of documentation techniques based on section 5.2,
Visibility of accessibility features, in the March 9th techniques document
appears below.
http://www.w3.org/WAI/UA/WD-WAI-USERAGENT-19990309/wai-useragent-tech.html 

 Prior to that section is a numbered list of changes or comments.

Thanks,
Kitch


1. I am still concerned that developers will read checkpoint 4.1.2 and
assume that all documentation and help will have to be in HTML. Or I'm
afraid they might say my help system in not HTML so this doesn't apply. I
know that on the teleconference people felt that the web content guidelines
were general enough to cover other non-HTML formats but I would like some
additional convincing.
2. I took out reference to getting installation instructions by fax or from
the web. Aren't we assuming that users might not have access to the web at
the time they are installing a user agent?
3. I changed some of the text in the introductory paragraph
4. I took out the reference to proprietary formats since the checkpoint
says use open standard. Could someone argue that PDF is an open standard
since users can access the Reader for free? 
5. I took out reference to RFB&D and said manufacturers should contract
those services if necessary.




Access to features that effect a user agent's accessibility should be
integrated into the user agent's menus and dialogs. Developers should avoid
regrouping accessibility features into specialized menus. Documentation
includes any instructional or reference material associated with the user
agent including user manuals, help systems, reference cards, and
registration materials. Users must have access to installation information,
either in electronic form on a diskette or CD or by telephone. 


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

[Priority 2] 

For instance, include references to accessibility features in these places:

   1.Indexes. Include terms related to product accessibility in the
documentation index (e.g., "accessibility", "disability" or "disabilities"). 
   2.Tables 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, set the default font, turn images on or off) as
specified by the documentation. 
   4.Include a list of all keyboard shortcuts in the accessibility section
of the documentation. 


[Checkpoint 4.1.2] Ensure that all product documentation conforms to the
Web Content Accessibility Guidelines ([WAI-PAGEAUTH]). [Priority 1] 


Electronic documentation created in open standard formats such as HTML, XML
and ASCII can often be accessed in the user's choice of application such as
a word processor or browser. Accessing documentation in familiar
applications is particularly important to users with disabilities who must
learn the functionalities of their tools, be able to configure them for
their needs, and to be compatible with assistive technology. 

Users with print impairments may need or desire documentation in
alternative formats such as Braille, large print, or audio tape. User agent
manufacturers may provide user manuals in alternative formats. If
necessary, manufacturers should contract with third party providers of
accessible materials to have their documentation converted into braille,
large print or audio tape. 

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, "Select the Home button on the toolbar or select
"Home" from the Go menu to return to the Home page. "

Received on Friday, 12 March 1999 13:52:42 UTC