Guideline 2.1

I think we can drop 2.1.4, since it is covered already by 2.1.5. I also think
that 2.1.3 is really talking about allowing multiple views, and is only P2. I
think we should have a checkpoint which says "make the tool accessible" -
possibly replacing 2.1.1 and 2.1.2 

As techniques for 2.1.7 I suggest that the techniques for 2.7.9 (allow the
author to perform tag transformations) apply, as well as allowing the author
to cut and paste structured sections of the document including markup. I am
not sure whether 2.7.9 is redundant with 2.1.7 - it seems possible.

I have put together some material based largely on the Microsoft and IBM
guidelines which I suggest be used as techniques for 2.1, which I have
included at the end of this message.

Some of these ideas are based on discussions with Phill, and I am expecting
that he and Bruce will come up with concrete suggestions for this or the next
meeting, so the only things I am putting as proposals are the techniques, for
now.

   General principles
     * User Configurability
     * Device independence
          + Choice of input device
          + Choice of output device
     * Consistency
     * Compatibility through APIs
       
   Standards
     * Draw text and objects using system conventions
     * Provide a consistent user interface
          + Make mouse, keyboard, and API activation of events consistent
     * Provide a User Interface which is "familiar" (to system standards,
       or across platform)
     * Use system standard indirections wherever possible
     * Ensure all dialogs, subwindows, etc meet these requirements
     * Avoid blocking assistive technology functions (sticky/mouse keys,
       screenreader controls, etc) where possible
       
   Keyboard access:
   
   Most input devices can be used to emulate key presses
     * Provide Keyboard access to all functions
     * Document all keyboard bindings
     * Provide customizable keyboard shortcuts for common functions
     * Provide logical order for interface via keyboard
       
   Mouse Input
   
   Input devices which are not very good for keyboard emulation, or which
   are used by people with poor keyboard skills, often emulate mouse
   input
     * Provide mouse access to functions where possible
       
   Icons, sounds
     * Provide visual (text) equivalents for sound warnings
     * Allow sounds to be turned off
     * Provide text equivalents for images/icons
     * Use customizable (or removable) colours/patterns
     * Ensure high contrast is available (as default setting)
     * Provide text equivalents for all audio
       
   Layout
     * Do not rely on color alone for meaning. Use color for
       differentiation, in combination with acessible cues (text
       equivalents, natural language, etc)
     * Position text labels and related objects consistently, and in an
       obvious manner (labels before objects is recommended)
     * Group related controls
       
   User focus and control
     * Clearly identify the user focus (and expose it via API)
     * moving focus should not cause unexpected events
     * Allow user control of timing - delays, time-dependent response,
       etc

--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 Monday, 24 May 1999 17:40:40 UTC