RE: feedback on the techniques for authoring tools Accessibility April 21st, 2000 working draft

Hi Heather,

thanks for the comments. Can you make them (where applicable) in the form of
proposals to change the document?

(Some additional responses interspersed...)

On Thu, 4 May 2000, Heather Swayne wrote:

  Guideline 4:
               The general descriptive text at the beginning of this guideline
  does a nice job of describing configurability, but the following 2
  techniques feel like you're forcing very specific actions:
  *	Highlight problems detected when documents are opened, when an
  editing or insertion action is completed, or while an author is editing.
  Using CSS classes to indicate accessibility problems will enable the author
  to easily configure the presentation of errors.  
  *	Alert authors to accessibility problems when saving.

CMN The techniques document is not forcnig anyone to do anything - it is
example ideas. We should make this more clear perhaps.
   
HS
  Guideline 5:
               In the general descriptive text at the beginning of this
  guideline, I would suggest pointing out that software applications that
  integrate new features into the current usage patterns of their users (as
  opposed to creating entirely new methods for their users to accomplish a
  task) are more successful at getting users to discover and use these new
  features.  New features that require training, additional divergent steps,
  or changes to the users current patterns are generally unsuccessful.
  
CMN I agree. 
 
HS
  Guideline 7:
               Does not include a reference to the MSAA implementation
  guidelines, although they are listed in the reference section of the
  techniques guideline.  I'm not sure if this is an oversight, or was
  deliberately left out.

CMN Oversight. Action editors...

Received on Tuesday, 9 May 2000 16:06:07 UTC