re: other application accessibility guidelines

This is from the User Agent group, prepared by Mark Novak of TRACE. It lists
several sets of guidelines which should be reviewed.

Charles

=====

Date: Tue, 9 Mar 1999 17:56:45 -0500
To: jongund@staff.uiuc.edu
From: mark novak <menovak@facstaff.wisc.edu>
Cc: w3c-wai-ua@w3.org
Subject: 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 ???

==============
At 10:08 AM -0400 5/20/99, Charles McCathieNevile wrote:
>Hi Mark.
>
>Did that draft actually include the various points made, or just refer to the
>other guidelines?
>
>Charles
>
>On Thu, 20 May 1999, mark novak wrote:
>
>  hi Ian
>
>  i remember drafting a section of the UA techniques doc., for Jon, probably
>  2 months back, which also talked about using the OS specific guidelines
>  for Mac, Win, X, etc., that might parallel this effort.  I don't know if
>that
>  text ever went anywhere, perhaps check with Jon?
>
>  mark
>
>  At 6:23 PM -0400 5/19/99, Ian Jacobs wrote:
>  >Hello,
>  >
>  >In the Authoring Tools Working Group meeting today (minutes [1])
>  >we discussed creating a W3C Note that would document
>  >(by inclusion or reference) vendor/platform-specific accessibility
>  >guidelines for applications. Charles McCathieNevile and I have
>  >proposed to gather information from vendors and create a W3C
>  >Note that could be referenced (as a source of Techniques)
>  >from both the User Agent and Authoring Tool Accessibility
>  >Guidelines.
>  >
>  >For UA, this relates directly to checkpoint 7.2.4 of [2], which reads:
>  >
>  >      "Follow operating system conventions and accessibility
>  >       settings in user interface design, configuration
>  >      (including configuration profiles), product installation,
>  >      and documentation."
>  >
>  >After putting together a draft of the Note, Charles and I intend
>  >to bring it to each of the AU and UA Working Groups for review.
>  >
>  >Comments on this proposal are encouraged.
>  >
>  > - Ian
>  >
>  >P.S. For a preview of what type of information would be included,
>  >refer to Charles' emails (Ibm Guidelines[3],
>  >MS Guidelines [4]) to the AU list on this subject.
>  >
>  >[1] http://www.w3.org/WAI/AU/telecon-19may99
>  >[2] http://www.w3.org/TR/1999/WAI-USERAGENT-19990331
>  >[3] http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0232.html
>  >[4] http://lists.w3.org/Archives/Public/w3c-wai-au/1999AprJun/0231.html
>  >--
>  >Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
>  >Telephone May 1999 only:     (212) 688-4489
>  >Cell phone May 1999:         (917) 450-8783
>  >Otherwise Tel/Fax:           (212) 684-1814
>
>
>
>
>--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, 20 May 1999 10:41:09 UTC