How to Develop Accessible Linux Applications
Sharon Snider
Copyright © 2002 by IBM Corporation
v1.1, 2002-05-03
| Revision History | ||
|---|---|---|
| Revision v1.1 | 2002-05-03 | Revised by: sds |
| Converted to DocBook XML and updated broken links. | ||
| Revision v1.0 | 2002-01-28 | Revised by: sds |
| Wrote and converted to DocBook SGML. | ||
- Table of Contents
- 1. Introduction
- 2. Developing Accessible Applications
- 3. Guidelines for Developing Accessible Applications
-
- 3.1. Keyboard Navigation
- 3.2. Mouse Interaction
- 3.3. Graphical Elements and Objects
- 3.4. Fonts and Text
- 3.5. Color and High Contrast Settings
- 3.6. Magnification
- 3.7. Audio
- 3.8. Animation
- 3.9. Focus
- 3.10. Visual Focus Indicator
- 3.11. Timing
- 3.12. Documentation
- 4. Additional Resources:
1. Introduction
This document provides developers with the information necessary to assess their applications for accessibility. Some of these tests should be performed using various types of adaptive technologies.
Please send any comments, or contributions via e-mail to This e-mail address is being protected from spambots. You need JavaScript enabled to view it . This document will be updated regularly with new contributions and suggestions.
2. Developing Accessible Applications
Some of the most important reasons for developing accessible software are:
-
Software should be accessible to as many users as possible.
-
Accessibility to new products benefits everyone. Information technology has provided many benefits to society. However, individuals with disabilities can not participate fully when the technology does not meet the needs of users with disabilities.
-
Compliance with worldwide regulations and standards such as Section 508 of the Rehabilitation Act, Americans with Disabilities Act and the World Wide Web Consortium's Web Accessibility Initiative.
2.1. Principles for Developing Accessible Applications
-
Choice of input methods. Support should be available for various types of input, such as, keyboard, mouse and adaptive technologies. Pay close attention to keyboard navigation.
-
Choice of output methods. Support should be available for various types of output, such as, visual display, audio, and print. The main focus is that text labels are provided for all user interface elements and objects, graphics, and icons.
-
Consistency and flexibility with the user's system configuration. In addition, include customization options so the user can select color, font, and layout of the work area.
3. Guidelines for Developing Accessible Applications
3.1. Keyboard Navigation
3.1.1. Guidelines
-
Efficient keyboard access is provided to application features.
-
A logical keyboard navigation order has been implemented.
-
The correct tab order is used for controls that are dependent on check boxes, radio buttons, or toggle state.
-
Keyboard access does not override existing accessibility features.
-
The application provides more than one method to perform keyboard tasks whenever possible.
-
There are alternate key combinations whenever possible.
-
There are no awkward reaches for frequently performed keyboard operations.
-
The application does not use repetitive, simultaneous key presses.
-
The application provides keyboards equivalents for all mouse functions.
-
The application does not use any general navigation functions to trigger operations.
-
All the keyboard invoked menus, windows, and tool tips appear near the object they relate to.
3.1.2. Tests
-
Context sensitive menus display correctly.
-
Any functions listed on the tool bar can be performed using the keyboard.
-
You can operate every control in the client area of the application and dialog boxes.
-
Text and objects within the application can be selected.
-
Any keyboard enhancements or shortcuts are working as designed.
3.3. Graphical Elements and Objects
3.3.1. Guidelines
-
There are no hard-coded graphical attributes, such as, lines, borders, or shadow thickness.
-
There are descriptive names for all application program interface (API) objects.
-
All multi-color graphical elements can be adjusted to monochrome only, whenever possible.
-
All interactive graphical user interface (GUI) elements are easily identifiable.
-
An option to hide non-essential graphics has been provided.
3.4. Fonts and Text
3.4.1. Guidelines
-
All the font styles and sizes are not hard-coded.
-
An option to turn off graphical backdrops has been provided.
-
All label objects have names that make sense when taken out of context.
-
There are no label names that have been used more than once in the same window.
-
There is consistency with label positioning throughout the application.
-
When using static text as a label for a control, the label immediately precedes the control in tab order.
-
An alternative to what you see is what you get (WYSIWYG) is provided.
3.4.2. Tests
Run the following tests to confirm that font size and settings are maintained.
-
Change the font in the application and confirm that the changes apply only to the application and not the desktop environment.
-
Change colors within the application and confirm that the changes apply only to the application and not the desktop environment.
-
Run a screen magnification program and test the font, color, and size of text when being viewed through a magnifier.
3.5. Color and High Contrast Settings
3.5.1. Guidelines
-
The application color is not hard-coded and can be changed.
-
Color is used as an enhancement and not the only way to convey information.
-
The application supports various high contrast settings (For example, black on white, or white on black).
-
The application is not dependent on a particular high contrast setting.
3.5.2. Tests
Run the following tests and verify that:
-
All information is available by printing a screen shot to a black and white printer.
-
All information is conveyed correctly when settings are set to only black and white or high contrast.
-
At least three high contrast schemes are available, and they function correctly.
-
High contrast settings in the desktop environment are respected by the application (For example, the window bar and font colors that are set by the desktop environment do not change).
3.6. Magnification
3.7. Audio
3.7.1. Guidelines
The following are guidelines for audio output. Using a screen reader, confirm that:
3.8. Animation
3.9. Focus
3.9.1. Guidelines
-
Focus starts at the most commonly used controls.
-
The current input focus is clearly displayed at all times.
-
The input focus is in the active display panel.
-
The appropriate feedback is provided when the user attempts to navigate past the end of a group of related objects.
-
The default audio alert is played when the user presses an inappropriate key.
3.10. Visual Focus Indicator
3.10.2. Tests
Test the following using a screen reader or Braille device. You should verify that:
-
When moving among objects the visual focus indicator is easy to identify.
-
Keyboard navigation through the application menus is clearly visible when the focus moves.
-
The screen reader or Braille device is tracking the visual focus indicator as you navigate using a keyboard.
-
When running a screen magnification program that the magnifier can track the visual focus indicator accurately as you navigate using the keyboard and mouse.
3.11. Timing
3.12. Documentation
3.12.1. Guidelines
The following are guidelines for writing accessible documentation:
-
All documentation is in an accessible format (For example, HTML, or text).
-
Documentation is available on all accessibility features of the application.
-
State if the application does not support the standard keyboard access that is used by the operating system.
-
Identify if there are unique keyboard commands.
-
Identify and explain all accessibility features.
-
When documenting mouse actions, include the alternative keyboard action as well.
4. Additional Resources:
-
American Foundation for the Blind provides information on creating accessible applications at http://www.afb.org/.
-
GNOME Accessibility Project has written a guide specifically for application development in the GNOME 2.0 desktop. It includes information using their Accessibility Tool Kit (ATK). Additional information is available at http://developer.gnome.org/projects/gap/guide/gad/index.html.
-
IBM Accessibility Center provides links to a Java, Web, and Software accessibility checklist for application development. This site is located at http://www-3.ibm.com/able/guidelines.html.
-
Sun Accessibility provides accessibility information on designing accessible Java applications. More information is available at http://www.sun.com/access/developers/software.guide.html.
-
The Web Accessibility Initiative Web site includes guidelines, checklists, and techniques for developing accessible Web sites and applications. Additional information is located at http://www.w3.org/WAI/.






Comments
Subscribe to Comments Feed