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