W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 1999

IBM guidelines

From: Charles McCathieNevile <charles@w3.org>
Date: Wed, 19 May 1999 14:07:55 -0400 (EDT)
To: WAI AU Guidelines <w3c-wai-au@w3.org>
Message-ID: <Pine.LNX.4.10.9905191404400.13405-100000@tux.w3.org>
(This is a lynx dump)

   [1]skip navigation links 
   [2]Home [3]Solutions [4]Partners [5]Resources [6]Events [7]Guidelines 
[opened door to accessibility] Software accessibility

   Software comes in tremendous variety. There are editors, integrated
   development environments, presentation tools, word processors, spread
   sheets, notes database applications and web based solutions, to
   mention just a few. This document will provide the information that
   software developers need to make their software accessible to people
   who have disabilities.
   Table of Contents:
   [8]Overview of accessible software
   [9]Principles of accessible software
   [10]Checklist for accessible software
   [11]References and resources
Overview of accessible software

   It is not surprising that most software developers have never stopped
   to imagine a blind person using their product. It is inconceivable.
   How about a person who has no arms? No way! But these people and many
   others with an a tremendous variety of disabilities expect to use this
   tremendous variety of software just as their non disabled colleagues
   The key to the mystery of how people with severe disabilities could
   use a computer application is that they use what is called assistive
   technology. As a developer you don't have to worry about making your
   application talk, the blind user will have a screen reader, and the
   screen reader will do the talking. But, and it is a big 'but,' you do
   have to make sure that the screen reader can find the information that
   it needs to do the talking. A blind person can't use a mouse, so
   you'll need to make sure that anyone can use your software with just
   the keyboard. Unplug the mouse and try! There is some work that you
   the programmer will have to do to provide access from the keyboard and
   to be sure that all the necessary information is available to the
   screen reader.
   As an application software developer, you don't have to figure out how
   a person without arms will provide input to your application. There is
   assistive technology that the disabled person can use to provide
   keyboard input to your program. Speech input is another choice, and
   for that, all program features must be easily accessible from the
   keyboard. Keyboard access is essential for blind users, mobility
   impaired, and those choosing to use voice input.
   Sometimes assistive technology is unnecessary. Did you know that
   people with some forms of limited vision may be absolutely incapable
   of reading text on the usual black and white screen and yet be able to
   read the screen with the colors reversed, or even better, with yellow
   letters on a blue background? Such people don't need assistive
   technology if they can just change the background and foreground
   colors in the software.
   Most of the recommendations for accessibility are recommendations for
   good user interface design.
Principles of accessible software

   These 3 basic principles should be followed when developing software.
   Choice of input methods
          Support the user's choice of input methods including keyboard,
          mouse, voice, and assistive devices via the serial port. The
          primary requirement is to provide keyboard access (mouseless
          operation) to all features and functions of the software
          application. The operating system usually provides support for
          input via the serial port, keyboard movement of the mouse
          pointer, and other keyboard enhancements.
   Choice of output methods
          Support the user's choice of output methods including display,
          sound, and print. The primary requirement is to provide text
          labels for icons, graphics, and user interface elements and to
          support visual indications for sounds. Implementing the
          accessibility APIs (e.g., [12]Java Accessibility, Microsoft
          Active Accessibility, etc.) for the target platform will meet
          this principle.
   Consistency and flexibility
          Make the application consistent with the user's choice of
          system behavior, colors, fonts sizes, and keyboard settings.
          Provide a user interface that can be customized to accommodate
          the user's needs and preferences including fonts, colors , and
          display layout.
Checklist for accessible software

   Version 1.1 April 15, 1999
   This checklist has been updated based on the "[13]Requirements for
   Accessible Software Design," Version 1.1, March 6, 1997, published by
   the US Department of Education:
   Follow this checklist to make your software accessible. The best first
   step towards providing accessible applications is to use platform
   supported tools that promote accessibility.
   1.0 Keyboard Access
                                                             [INLINE] 1.1
   Provide keyboard equivalents for all mouse actions. Make all actions
   required or available by the program available from the keyboard. . .
                                                             [INLINE] 1.2
   Provide logical interaction with interface objects (logical tab order
   between buttons, lists, etc.). . .
                                                             [INLINE] 1.3
   Define accelerator, mnemonics or shortcut keys for tasks that are
   frequently performed (e.g., Ctrl+P for print, Escape for cancel). . .
                                                             [INLINE] 1.4
   Document all keyboard access with the product and/or follow documented
   operating system conventions. . .
   2.0 Accessibility Features
                                                             [INLINE] 2.1
   The software shall not interfere with existing accessibility features
   built into the operating system (e.g., Sticky Keys, Show Sounds,
   Serial Keys) . .
   3.0 Object Information
                                                             [INLINE] 3.1
   Provide a well defined visual focus indicator that moves among
   interactive objects as the input focus changes. This focus indication
   must be programmatically exposed to assistive technology. . .
                                                             [INLINE] 3.2
   Provide sufficient information about user objects such that assistive
   technology can understand how the objects are used (e.g., the object
   is a text box with a label "enter password," or a check box which is
   checked). . .
   4.0 Icons
                                                             [INLINE] 4.1
   Assistive technology must be able to associate text with icons. For
   example, the program can have text next to the icon, like the desktop
   icons in Windows 95 or the program can make text available as text
   pop-ups, tool-tips, or bubble help. . .
                                                             [INLINE] 4.2
   Provide consistent use of icons throughout the application. For
   example, if the application uses folders in several places, the folder
   icon should be the same for all of them. . .
   5.0 Layout
                                                             [INLINE] 5.1
   Associate labels clearly and/or programmatically with controls or
   objects . .
                                                             [INLINE] 5.2
   Position related objects near each other. . .
   6.0 Sounds
                                                             [INLINE] 6.1
   Provide a visual cue for all audio alerts. . .
                                                             [INLINE] 6.2
   If information is presented in audio format, it shall be capable of
   being displayed by the user in text format, either as closed
   captioning, a pop-up window, or other means, in parallel and/or in
   synchrony with the audio content. . .
                                                             [INLINE] 6.3
   Allow the user to disable sound and adjust the volume. . .
                                                             [INLINE] 6.4
   If important information is provided in video format, then the same
   information must be provided in an accessible format. For example,
   provide a video description for the video. . .
   7.0 Display
                                                             [INLINE] 7.1
   Use system text drawing tools or provide text through an API
   (application programming interface) supporting interaction with
   assistive technology. The minimum information that must be available
   to an assistive technology is text content, text input caret location,
   and text attributes. . .
                                                             [INLINE] 7.2
   Do not use color as the only way to convey information or indicate an
   action. The software shall provide another way to display the
   information for individuals who cannot identify or distinguish colors.
   . .
                                                             [INLINE] 7.3
   Provide a wide variety of user selectable color and font settings to
   better allow for high contrast color schemes, different background
   colors, large fonts and different font styles. Inherit and respect
   system-wide color settings the user has defined. . .
                                                             [INLINE] 7.4
   Provide the capability for users to turn off patterned backgrounds
   behind text or graphics. . .
   8.0 Timing
                                                             [INLINE] 8.1
   If timed responses or timed instructions are used by the software,
   then allow the user to adjust the response time or allow the
   instruction to persist. The software should allow the response time to
   be at least 5 times the average response time. . .
                                                             [INLINE] 8.2
   Allow the user to either slow down or disable rapid screen updates or
   flashing. For example, avoid seizure-inducing blinking or flashing
   rates for text or graphical elements at frequencies between 10-25 Hz.
   . .
   9.0 Documentation
                                                             [INLINE] 9.1
   Provide clear and precise documentation on all accessibility features.
   . .
                                                             [INLINE] 9.2
   Provide documentation in an accessible format, such as ASCII text or
   HTML. . .
   10.0 Verify Accessibility
                                                            [INLINE] 10.1
   Test the software against this checklist . .
                                                            [INLINE] 10.2
   Test the software to ensure to ensure all actions are available from
   the keyboard. . .
                                                            [INLINE] 10.3
   Test the software using assistive technologies (e.g., accessibility
   test tools, screen readers, screen magnifiers, high contrast schemes,
   or show sounds options) and/or include people with disabilities in
   beta tests and usability tests of the software. . .
References and resources

   "EITACC Desktop Software standards":
          Electronic Information Technology Access Advisory (EITACC)
   "Requirements for Accessible Software Design":
          US Department of Education, version 1.1 March 6, 1997.
   "Java accessibility guidelines and checklist":
          IBM Special Needs Systems.
          [16]www.austin.ibm.com/sns/accessjava.html. This site contains
          detailed guidelines for the Java environment.
   "Windows accessibility guidelines":
          Microsoft. [17]www.microsoft.com/enable/dev/guidelines.htm.
          This site contains detailed guidelines specific to the
          Microsoft Windows software environment.
   "Web accessibility guidelines and checklist":
          IBM Special Needs Systems.
          [18]www.austin.ibm.com/sns/accessweb.html. This site contains
          detailed guidelines for the Web and HTML.
   "Lotus Notes accessibility guidelines":
          IBM Special Needs Systems.
          [19]www.austin.ibm.com/sns/accessnotes.html. This site contains
          detailed guidelines for accessible Lotus Notes applications.
   "What is Accessible Software":
          James W. Thatcher, Ph.D., IBM, 1997.
          [20]www.austin.ibm.com/sns/software.html. The paper discusses
          problems encountered by computer user who have disabilities and
          what developers can do to make their software accessible.
   "Making the GUI Talk":
          Richard S. Schwerdtfeger, IBM, 1993.
          [21]ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt. This
          paper discusses "Off-Screen Model" technology and GUI Screen
   "Towards Accessible Human-Computer Interaction":
          Eric Bergman, Earl Johnson, Sun Microsytems 1995.
          [22]www.sun.com/tech/access/updt.HCI.advance.html. This paper
          discusses accessible user interfaces.
   [23]Home [24]Solutions [25]Partners [26]Resources [27]Events
   [28]Accessibility guidelines [29]IBM Home [30]IBM Legal 
                  [31]Valid HTML 4.0! [32]Bobby approved! 
                           1998 IBM Corporation


   1. file://localhost/home/charles/gl/accesssoftware.html#navskip
   2. file://localhost/home/charles/gl/index.html
   3. file://localhost/home/charles/gl/solutions.htm
   4. file://localhost/home/charles/gl/partners.htm
   5. file://localhost/home/charles/gl/resources.htm
   6. file://localhost/home/charles/gl/events.htm
   7. file://localhost/home/charles/gl/guidelines.htm
   8. file://localhost/home/charles/gl/accesssoftware.html#summary
   9. file://localhost/home/charles/gl/accesssoftware.html#principles
  10. file://localhost/home/charles/gl/accesssoftware.html#checklist
  11. file://localhost/home/charles/gl/accesssoftware.html#references
  12. file://localhost/home/charles/gl/accessjava.html
  13. http://ocfo.ed.gov/coninfo/clibrary/software.htm
  14. http://trace.wisc.edu/docs/eitacc_desktop_software_standards/desktop_software_standards.htm
  15. http://ocfo.ed.gov/coninfo/clibrary/software.htm
  16. http://www.austin.ibm.com/sns/accessjava.html
  17. http://www.microsoft.com/enable/dev/guidelines.htm
  18. http://www.austin.ibm.com/sns/accessweb.html
  19. http://www.austin.ibm.com/sns/accessnotes.html
  20. file://localhost/home/charles/gl/software.html
  21. ftp://ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt
  22. http://www.sun.com/tech/access/updt.HCI.advance.html
  23. file://localhost/home/charles/gl/index.html
  24. file://localhost/home/charles/gl/solutions.htm
  25. file://localhost/home/charles/gl/partners.htm
  26. file://localhost/home/charles/gl/resources.htm
  27. file://localhost/home/charles/gl/events.htm
  28. file://localhost/home/charles/gl/guidelines.htm
  29. http://www.ibm.com/
  30. http://www.ibm.com/legal
  31. http://validator.w3.org/
  32. http://www.cast.org/bobby

--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 Wednesday, 19 May 1999 14:07:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:28:21 UTC