Re: Developer feedback on "Techniques for Authoring Tool Accessibility" - 7.1

Marjolein, some specific answer to your feedback. In some cases I have
prpopsed changes to the lists of techniques - the proposed new text is
given. In other cases I have asked further questions which I hope you or
someone else can clarify.

Cheers

Charles


7.1 techniques - the list of techniques

 Note1: These requirements apply to all parts of a tool - the main interface,
documentation and help, and subwindows, plugin tools, etc.

System standards
 + Use system conventions rather than specially written procedures to draw
text and objects. Otherwise Assistive technologies may not be able to access
them. (See references above for specific systems)
 + Make activation of controls through an API (for example by an assistive
technology) and keyboard and mouse activation behave in a consistent manner
 + Provide a user intereface that is familiar (unchanged)
 + Use system standard APIs wherever possible. These provide indirect ways of
performing functions that can be intercepted by different input and output
devices including other software.)
 + moved to note1
 + Avoid blocking standard assistive technology functions such as sticky keys
and mouse keys (link to standards known)

Configurability
 + unchanged
 + this could be deleted - it is essentially the same as the next one.
 + unchanged

Input device independence
  What is a docked / undocked form?

Icons, Graphics, sounds
  Yes, there may be drastically different ways of achieveing this for
different components (and more obviously, for different tools). But is the
requirement unclear?
  Does High conttrast need to be a default setting? It should be possible to
make it the user's default setting. Thoughts anyone?

Layout
 colons are helpful in identifying related labels, but explicit markup is
much better. And they only apply in some languages. Should we mention them?

User focus
  + Clearly expose the user focus. Where a Document model is available
through an API, include the location of the current focus in that model.
  + Do not cause unexpected events to be triggered by viewing content. For
example, it must be possible to view and inspect (and edit the properties 
of) an active element without activating it.
  + Allow the user to pause, step through or slow the rate of time-dependent
responses (for example in putting stop marks into time-based presentations
such as an audio stream
  + unchanged

Received on Sunday, 2 April 2000 00:46:22 UTC