example text for techniques 7.2.3 per action item

hi Jon

enclosed is the result of my first pass at text ideas for the UA Techniques
section 7.2.3.   the sections are divided up per your ideas of

1. what to do,
2. what not to do, and
3. how to test if you did it correct.

munch away ;)

Mark

from the current (19990210) Guidelines:
7.2.3 [Priority 2]
	Use the standard interfaces defined for the operating systems.


from the current (19990210) Techniques:
7.2.3 Use the standard interfaces defined for the operating systems.
[Priority 2]

	Use standard rather than custom controls when designing user
agents.  Third
party assistive technology developers are more likely able to access
standard controls
than custom controls.  If you must use custom controls, review them for
accessibility
and compatibility with third party assistive technology.



========== new text for the Techniques for 7.2.3 ==========

(Note:  there is an lot of variability in the term "standard interface".
Do we want to back
up and further define what is meant by a "standard interface"? )



***WHAT TO DO***

A)  Develop your UA User Interface (UI) with standard interface components
per the
target platform(s).  Most major operating system platforms provide a series of
design and usability guidelines, these should be followed when possible.
For example:

- Windows applications
 http://www.microsoft.com/enable/dev/apps.htm

Microsoft includes things like a "Checklist of Accessibility Design
Guidelines" at
this web site.  The checklist includes topics like providing keyboard
access to all
features, exposing keyboard focus within a control, and to avoid conveying
important information by color alone.

- Macintosh applications
http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-2.html

Apple includes information on topics like responses to user input via the
keyboard
and mouse, clear and consistent use of language, and designing for an
international
market.

- UNIX/ X Window System
http://www.opengroup.org/publications/catalog/mo.htm

The Open Group has various guides which explain the Motif and Common Desktop
Environment (CDE) with topics like how users interact with Motif/CDE
applications and how to customize these environments.

These checklists, style guides, and human interface guidelines provide very
valuable information for developing applications (e.g., UAs) for any
platform/operating system/GUI.   (this next sentence kind of combines
7.2.2 ???)  If your custom interface cannot provide information or
operation as defined above, then you may need to design your UA using
any additional options provided by that platform.  (Note, Microsoft
now requires some accessibility related functions as part of its "Windows"
logo program.  For more information, please visit:
http://www.microsoft.com/enable/dev/logo.htm .)

- Microsoft Windows offers additional libraries and tools known as
Active Accessibility (see section 2).
- SUN's Java has a suite of UI components and controls with accessibility
built in, known as the "Swing" classes (see section 2).



*** WHAT NOT TO DO: ***

B)  Evaluate your standard interface components on the target
platform against any built in operating system accessibility
functions (see Appendix 8) and be sure your UA operates
properly with all these functions.

Examples:

- Microsoft Windows supports an accessibility function called
"High Contrast".  Standard window classes and controls automatically
support this setting.  However, applications created with custom
classes or controls must understand how to work with the "GetSysColor"
API to ensure compatibility with High Contrast.

- Apple Macintosh supports an accessibility function called "Sticky Keys".
Sticky Keys operates with keys the operating system understands to be
defined as modifier keys, and therefore a custom UA control should not
attempt to define a new modifier key.



*** HOW TO TEST IF YOU DID IT CORRECT ***

C)  Ensure your UA can be operated using the standard interfaces
on the target platform(s).  (Are we limited to desktop UA for now ??)

Examples (for more examples, please refer to the guidelines
and/or checklists in section A):

- all functional UI components must be keyboard accessible and
therefore, must be oper-able by software or devices which emulate
a keyboard (Use SerialKeys [see Appendix 8] and/or voice recognition
software to test keyboard event emulation.).  Individuals with
varying physical abilities should be able to access your UA using a
SerialKeys device or using voice recognition, provided it is keyboard
accessible.

- all functional UI components must track selection and focus.  Individuals
who have low vision and use screen magnification software should be
able to follow highlighted item(s) (e.g., selection), text input location
(e.g., sometimes referred to as the "caret"), and any control or component
with focus, if your UA exposes these properties correctly.

- all functional UI components must provide readable "text" names or
labels, even when not visible.  Providing this type of information in
your UA along with the prior two examples, means that individuals
who are blind and accessing your UA using screen reading software
and/or a Braille output device should be able to operate and navigate
within it.

- all functional UI components which convey important information
using sound, also need to provide alternate, parallel visual representation
of the information for individuals who are deaf, hard of hearing, or
operating your UA in an environment where the use of sound isn't
practical.

- we may want to add an example of cognitive/LD as well ???

- others, or is this too long already ???

Received on Tuesday, 9 March 1999 18:56:37 UTC