Re: Issue with Checkpoints 2.7.1 and 2.7.2

I think itis possible to satisfy 2.7.2 without satisfying 2.7.1 - whatever
help is available includes the relevant accessibility features without
documenting all the accessibility features. I suspect that it would take a
contrived case to demonstrate this.

I would go along with making 2.7.2 a technique
if the following things are clear:

1. The help system is included in the integration of look and feel
checkpoint, which could be done by suggesting some areas for consideration
in techniques for look and feel. (i.e. accessibility help is not a
cyber-ghetto chapter for people who want to be nice to disabled people.)

2. Help examples should always be accessible examples - IMG should have
ALT, and if relevant LONGDESC (this is also crossover with the look and
feel stuff as per Kynn's proposal) etc

I think that a lot of this is already covered in the techniques section
for this guideline, which is encouraging.

Charles

On Thu, 8 Apr 1999, Bruce Roberts/CAM/Lotus wrote:

       After the tele-conference it hit me as to why I felt uncomfortable
  with checkpoints 2.7.1 and 2.7.2.  First, let me put these checkpoints in
  my own words to be sure I'm understanding their intent correctly:
  
  2.7.1:  [Priority 1] The authoring tool should have explanations of its
  accessible authoring practices in its help system(s) (context sensitive
  help, on-line documentation, hardcopy documention, etc.).
  
  2.7.2:  [Priority 2] The authoring tool should have explanations of it's
  accessibility features clearly called out in each help topic. (example:
  help discussion for adding an image also describes how to add alt text)
  
  
       If my understanding of these is correct, then satisfying 2.7.2, a
  specific way of integrating with help, satisfies 2.7.1, the more general
  help requirement.  This means that it's easy for the authoring tool
  developer to satisfy a P1 and skip the P2, not a good thing I think.
  
       I propose a general principle for checkpoints is to make them as
  disjoint as possible.  When they're not disjoint we need to be more careful
  in assigning priorities.
  
       Some ideas for fixing this particular case are:
  
       1)  Make 2.7.2 a technique for 2.7.1
       2)  Eliminate 2.7.2 and:
            2.1)  Expand 2.7.1 to call out each part of the authoring tools
  help systems and how accessible authoring practices should be integrated.
                 or
            2.2)  Create seperate checkpoints for each help system that
  prescribe integration.
       4)  Give 2.7.2 a priority 1.
  
  I lean to number 1.
  
  -- Bruce
  
  

--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 Thursday, 8 April 1999 10:49:15 UTC