Re: revised documentation techniques

It seems to me fine that there is a set of accessibility features which
are provided in one place, so long as they are also avilable in relevant
parts of the full user interface.

For example,

Controlling whether ALT text is rendered is an accessibility feature. It
is also a general presentation issue, along the lines of font sizes (which
are themselves accessibility controls) and the controls make sense grouped
together in a set of rendering controls.

In an index, one might expect to find:

* ALT text, rendering of 
* alternative content
* rendering controls
* accessibility controls

all referring to the same point.

(I should point out that this is an arbitrary example. Another product
might group alternative content with image and multimedia handling.)

I think we should also point out what we think of as accessibility
features. As a start, I would include those things which are mentioned as
checkpoints.

Charles McCN


On Fri, 12 Mar 1999, Kitch Barnicle wrote:
  
  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. " 
  
  
  
  
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Friday, 12 March 1999 14:08:13 UTC