From the web page
http://www.austin.ibm.com/sns/guidelines.htm
Guidelines
Successful access to information and use of information
technology by people who have disabilities is known as
"accessibility". Following these guidelines and using these
tools will ensure developers and content providers understand
why and what they need to do to make all of their technology and
information accessible to people who have disabilities. Please
read the sections below on " Needs of users who have
disabilities" and " Why accessibility" to get a good background
awareness of the concerns.
Accessibility Guidelines
Software Accessibility
* Overview of accessible software
* Principles of accessible software
* Checklist for software accessibility, version 2.1
* References and resources.
Web Accessibility
* Checklist for Web accessibility, version 2.1
* Rationale, Techniques, Testing
* References and resources.
Java tm Accessibility
* Checklist for accessible Java applications, version 2.1
* Guidelines for writing accessible Java applications
* References and resources.
Lotus Notes Accessibility
* Checklist for accessible Lotus Notes applications, version
2.1
* References and resources.
Hardware Accessibility
* Checklist for accessible hardware, version 2.1
* Guidelines for accessible hardware
* References and resources.
Needs of users who have disabilities
Meeting the standards of accessible software first requires an
awareness of the special needs of users who have disabilities.
The blind cannot use a mouse because it is a hand-eye
coordinated device, so every application must be operable with
just the keyboard. The blind and others with dyslexia and
low-vision also rely on assistive technology know as a screen
reader that reads the screen's information, controls, buttons,
and text to the user. Today's screen readers transform the
visual interface into an audio interface that the blind and
others can use.
Those users with low-vision and color blindness have difficulty
perceiving information that is presented by differences in
color, contrast, depth, size, location or font differences
alone. A good example would be when both color and a fill
pattern is used to denote different bars on a graph so they can
be when viewed in either color or black and white. A poor
example would be using only the size attribute in HTML to denote
a heading; the heading element tag should be used to correctly
mark-up the structure of the Web page.
The deaf and hard of hearing have many of the same needs as
those users who do not have a sound card or who work in a noisy
environment and need information presented visually in addition
to the audio means. For example, closed captions, blinking error
messages, and transcripts of the speaking audio are necessary
for the deaf and hard of hearing.
The users with hand, arm, and other mobility impairments may not
be able to use multiple simultaneous key strokes such as
Ctrl+Alt+Del and therefore rely on special keyboard enhancements
in the operating system. Some users must rely on voice input and
navigation where possible. Others rely on changing settings to
allow them time to enter the information at their own pace, one
keystroke at a time. The developer and Web page author do not
have to figure out how all the different people with
disabilities will use their information technology if they
follow these established guidelines and checklists.
Why accessibility?
The rights of disabled employees includes access to information
to be able to do their jobs. The purchasing requirements of
government agencies and large corporations require accessible
software. These rights and requirements are being established in
legislation around the world similar to the United States's
Americans With Disabilities Act (ADA) and the Telecommunications
Act. An additional reason to meet these standards and guidelines
of accessibility comes from the benefits derived. All users
benefit when they can use voice navigation, all test groups can
benefit when they can automate complete test cases via the
keyboard, and all Web authors can benefit when the same Web page
can to viewed, printed, listened to, or browsed in Braille with
no extra work by the author.
IBM has a tradition of leading the industry in providing
accessible technologies to people who have disabilities. We are
sharing our guidelines with developers of hardware, software,
Javatm, and Web solutions. Please use the resources found on
this page to produce accessible solutions. You are also invited
to give us feedback.
----------
>From the web page
http://www.austin.ibm.com/sns/accesssoftware.html
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:
Overview of accessible software
Principles of accessible software
Checklist for accessible software
References and resources
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 a tremendous variety of
disabilities expect to use this tremendous variety of software
just as their non disabled colleagues do.
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.
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., 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.
IBM Software Accessibility Checklist - Version 2.1
January 11, 2000
* *This checklist was originally based on the "Requirements
for Accessible Software Design," Version 1.1, March 6, 1997,
published by the US Department of Education:
http://ocfo.ed.gov/coninfo/clibrary/software.htm We have drawn
heavily on the Microsoft Windows Guidelines for Accessible
Software Design for rationale and techniques.
1.1 Keyboard equivalents
Provide keyboard equivalents for all mouse actions.
1.1 Rationale.
Users with a mobility impairment may not be able to use the
mouse because of the fine motor control required to move the
mouse. Users who are blind cannot use the mouse to navigate
software because it depends on visual feedback of the location
of the mouse pointer. Therefore, it is important to make all
mouse actions available through the keyboard. This includes
access to menus, toolbars, buttons and links. Providing a good
keyboard user interface is key to designing an accessible
application.
1.1 Techniques.
* Here is a document with Keys used in Windows. Applications
should be consistent with, and not interfere with, those keys
found throughout the operating system. The Microsoft Design
Guide includes Appendix B Keyboard Interface Summary, which
contains both operating system specific key commands, like
Ctrl+Alt+Del, and recommendations like ALt+F4 for close window,
and Ctrl+P for Print.
* In dialogs, allow the user to press the TAB key to move the
focus through the "hot spots" or active regions and to press the
ENTER key to choose the currently selected active region. The
SHIFT+TAB key combination is used to move backwards through
dialog. Use arrow keys to move between controls within a group
of controls.
* Provide keyboard commands (F6 or CTRL+TAB) to move between
window areas. For example, in Microsoft Windows' Multiple
Document Interface (MDI), use the F6 key and the CTRL+TAB key
combination to move the focus between panes and child windows.
* Windows software that normally hides some keyboard user
interface elements or omits some keyboard mechanisms altogether
should present them when the Keyboard Preference flag is set.
This flag, which is set by the user in Control Panel
(Accessibility Options/Keyboard/Show extra keyboard help in
programs), advises an application that the user relies on the
keyboard rather than a pointing device, so additional support
should be provided where appropriate. An application can test
for this flag by calling the SystemParametersInfo function with
the SPI_GETKEYBOARDPREF value.
1.1 Testing.
Unplug the mouse and navigate to each feature using the keyboard.
1.2 Document Keyboard Access
Follow documented operating system conventions for keyboard
access. Document keyboard access that is unique to the product.
1.2 Rationale.
Since most software is mouse driven, it may not be clear how to
access functions using the keyboard. Without this documentation,
you cannot use the software with the keyboard. Documentation
should include menu access, keyboard navigation, and keyboard
shortcuts. It is not necessary to document the keyboard access
for those functions which follow documented operating system
conventions. For example in Windows software, Tab moves through
a dialog, Alt+Tab moves through windows, Alt+F4 closes a window
and usually, Ctrl-O opens a document, Ctrl-S saves the document
and Ctrl-P prints the document.
1.2 Techniques.
* The Microsoft Windows Design Guide includes Appendix B
Keyboard Interface Summary, which contains both operating system
specific key commands, like Ctrl+Alt+Del, and recommendations
like ALt+F4 for close window, and Ctrl+P for Print.
* Provide keyboard accessibility documentation in the product
help. Include a keyword search for accessibility, disability,
and keyboard for easy identification.
* Provide index entries for accessibility, disability and
keyboard.
* In the product documentation, include a section called
"Keyboard access" where all accessibility features are
documented.
* Include keyboard equivalent function in the pull-down menus.
For example, to document the shortcut key for Save,
add Ctrl-S next to the Save command in the File pull-down menu.
Accelerator keys for menu items, indicated by the underline in
Windows, F for File, are "self documenting."
1.2 Testing.
* Open the software help menu. Search on the words keyboard,
accessibility or disability. Verify keyboard support is
documented in the help facility.
* Open the software documentation. Search on the words
keyboard, accessibility or disability. Verify keyboard
support is documented in the product documentation.
* If the product provides "how to" instructions and/or
context-sensitive help, verify that they include how to
perform actions using the keyboard in addition to using the
mouse?
* Open the software documentation. Search for "click" and be
sure that the corresponding keyboard activation is
documented along with the mouse action.
1.3 Accelerator, mnemonic or shortcut keys
Define accelerator, mnemonics or shortcut keys for tasks that
are frequently performed (e.g., Ctrl+P for print, Escape for
cancel).
1.3 Rationale.
Users who are blind or have certain motor disabilities must use
the keyboard to navigate an application. The decision of what
features to map can be made by determining which features are
key to the software such as functions on the task bar. People
with disabilities benefit from short cut (like Ctrl+P for Print)
because they can reduce time consuming steps that would
otherwise be required to activate the feature. For example, when
shortcut keys are provided for Print, users just press Ctrl-P.
Otherwise it takes 5-15 keystrokes to accomplish the same
action. Users must first use F10 to open the main menu, then
ENTER on the File menu item. They must then arrow down 5-10
times to get to the Print option and press ENTER. If the
accelerator key P for Print is available, the user presses F10
to open the menu bar, ENTER to select File, and then P for Print.
1.3 Techniques.
* Except when menus are dynamic, each menu item should have an
accelerator key and in F for File.
* For Windows software, The Microsoft Windows Keyboard Guide
documents the recommended keyboard user interface
conventions. This can serve as a valuable reference when
designing any keyboard user interface. You can download this
document from http://microsoft.com/enable/.
* Windows software that normally hides some keyboard user
interface elements or omits some keyboard mechanisms
altogether should present them when the Keyboard Preference
flag is set. This flag, which is set by the user in Control
Panel (Accessibility Options/Keyboard/Show extra keyboard
help in programs), advises an application that the user
relies on the keyboard rather than a pointing device, so
additional support should be provided where appropriate. An
application can test for this flag by calling the
SystemParametersInfo function with the SPI_GETKEYBOARDPREF
value.
1.3 Testing.
Unplug the mouse and navigate to each item on the action menu
and the action bar using the keyboard. Verify common tasks
(e.g., open, close, save, print) have shortcut keys.
1.4 Keyboard tab order
Provide logical interaction with interface objects (logical tab
order between buttons, lists, etc.).
1.4 Rationale.
A logical keyboard navigation order should be used to ensure
that dialog boxes and similar groups of objects can be traversed
in a logical order using the keyboard, normally from left to
right and top to bottom (for Western languages).
If the order does not follow this convention, it can be very
confusing to users who navigate using the keyboard. It is
especially confusing for people who are blind and rely on screen
readers. Users who are blind explore a dialog box sequentially,
instead of scanning the entire box as sighted users would;
random tab order can make the dialog box nearly unusable.
1.4 Techniques.
The tab order is the order in which the TAB key moves the input
focus from one control to the next within a dialog box. Usually
the tab order proceeds from left to right in a dialog box, and
from top to bottom.
For example, in Microsoft Visual C++ use Layout/Tab Order to
view and change tab orders or your dialogs.Use standard
programming practices for specifying the tab index for each
control in a dialog.
1.4 Testing.
Unplug the mouse and navigate forms and dialog boxes using the
keyboard. Verify the order in which objects are navigated makes
sense (usually left to right and top to bottom).
2.1 Accessibility features
Do not interfere with existing accessibility features built into
the operating system (e.g., Sticky Keys, Show Sounds, Serial
Keys).
2.1 Rationale.
Most operating systems have a set of Accessibility Options which
enable users to customize their setup for the keyboard, display,
sound and the mouse. For example, someone with a motor
disability may not be able to press multiple key strokes
simultaneously. Setting the Sticky Keys option enables them to
press the keys one at a time (e.g., Ctrl-Alt-Delete). Someone
who is deaf or hard-of-hearing would need to set the Sound
options so they get visual cues or captions for audio
information. These features make it possible for people with a
variety of disabilities to use their computer. If the software
interferes with these options these users may find their system
unusable.
2.1 Techniques.
* Do not use keyboard sequences reserved for the accessibility
features on your operating system.. Here are examples of
Keyboard Mappings taken from the Windows operating system.
Keyboard Mappings Mobility Access Feature
5 consecutive clicks of Shift key On/Off for StickyKeys
Right Shift held down 8 seconds On/Off FilterKeys
NumLock held down 5 seconds On/Off ToggleKeys
Left-Alt+Left-Shift+PrintScreen On/Off HighContrast
Left-Alt+Left-Shift+NumLock On/Off MouseKeys
* Avoid program defined shift states, other than Shift, Alt
and Control.
2.1 Testing.
* On the Keyboard page of the Windows Accessibility Options
from the Control Panel, set the "use sticky keys" option. In
"Settings," check "use shortcut." Using only one finger,
navigate in your application. Verify that all multiple key
strokes (e.g., Ctrl-P for print) can be activated using only
one finger. Activate the StickyKey feature with the
activation keyboard command (five clicks of the Shift key in
Windows).
* On the Sound page of Accessibility Options, check "use
SoundSentry." Verify that your application's system sounds
create a visual alert.
3.1 Object focus
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.
3.1 Rationale.
Even if the software provides keyboard access so users can
navigate the software, that isn't enough if you don't know where
you are. Keyboard users must be able to see the current focus
point to know what to do. Imagine typing if you could not see
the caret (insertion bar). Also assistive technology (e.g.,
screen readers, screen magnifiers) needs to know the position
and contents of the visual focus indicator, so it can describe,
magnify or manipulate the object for the user.
In an editing situation, the caret or insertion bar is the
visual focus. As a blind user moves the focus with the arrow
keys, a screen reader must know the position of that focus so
that it can echo the current character, word or line. Similarly,
as a user tabs around a dialog, a screen magnifier can follow
the visual focus.
3.1 Techniques.
For Windows software, the object focus can be provided through
the use of standard Windows controls, Microsoft Active
Accessibility (MSAA) programming interfaces or use of the system
caret. Each of these methods is described below. The Microsoft
accessibility team has authored a detailed guide for writing
accessible software which covers this point and many others.
The easiest way to provide object focus in Windows software is
through the use of standard Windows controls. Windows notifies
assistive technology when and window gets focus. It does this
using Active Accessibility, window hooks, and window messages.
When you use standard Windows controls no additional work is
required to provide visual focus.
If the software uses non-standard controls, Microsoft Active
Accessibility (MSAA) is the preferred method of exposing the
object focus location. The application must call NotifyWinEvent
whenever the focus moves to an object that does not correspond
to an entire window. It must handle the WM_GETOBJECT message
when that is used to query the focus object. COM objects
representing screen elements must also support the accSelection
property.
For more information about MSAA, refer to the Microsoft Active
Accessibility page.
Object focus can also be provided by positioning the system
caret on the focus object. The system caret is the blinking
vertical bar that the user sees when editing text, but it can be
placed anywhere on the screen, made any shape or size, and even
made invisible.
If the system caret is made invisible, it can be moved to
indicate the focus location to assistive technology without
disturbing what the user sees on the screen. This technique will
expose the focus to assistive technology; there still must be
some visual indication of the focus object.
3.1 Testing.
* Unplug the mouse. Using the keyboard, navigate through the
software, especially menus, dialogs, forms and property
boxes. Verify the visual focus is clearly visible and easy
to identify when you tab or arrow to the next object.
* Run Magnifier. As you navigate through the software, verify
Magnifier tracks the focus indicator and displays it in the
Magnifier window.
3.2 Object information
Provide sufficient information about user interface objects so
that assistive technology can understand how the objects are
used (e.g., the object is an edit field or a check box which is
checked).
3.2 Rationale.
Users who are blind use computers with the aid of assistive
technology such as screen readers or braille displays. The
assistive software must provide information about the objects so
a screen reader can tell its user what the focus object is as
well as its role and state. For example, if you tab through a
form and focus is on a radio button object, you need to know it
is a radio button and whether it is checked or not.
3.2 Techniques.
* The easiest way to provide object information in Windows
software is through the use of standard Windows controls. No
additional work is required for standard Windows controls.
* If the Windows software uses non-standard controls, MSAA is
the preferred method of exposing object information.
* If the application does not support MSAA, the following
steps can help make a control more compatible, but not fully
compatible, with accessibility aids. If the custom control
has its own window, you can return a descriptive string when
the control is queried using the WM_GETTEXT message. For
example, a control that appears as a button with the label
Print could return the string "Print button" to convey both
the control type and the label. The same string would be
appropriate if the control looked like a button but had a
graphic showing a printer rather than a textual label.
Likewise, a custom control that behaves like a check box
could return a caption string "Printing Enabled check box,
checked."
3.2 Testing.
Run Object Inspector. As you position the mouse over objects,
verify that the name, role, and state fields are available
through Object Inspector. If any fields are blank or have
incorrect information, this checkpoint is not met.
4.1 Labels associated with controls or objects
Associate labels clearly and/or programmatically with controls,
objects, and icons.
4.1 Rationale.
Labels name an object (e.g., icon names, window titles, button
labels, edit fields). The labels must be associated with the
object in order for the assistive technology to make them
available to the user.
4.1 Techniques.
* Use MSAA to expose the name and description of each image.
* Place text labels for objects immediately to the left or
immediately above the control. Screen readers use proximity
to identify labels if they are not exposed programmatically.
* Use the standard Windows tooltip control to apply a label to
each image.
* Avoid having multiple objects with the same name on the same
form or dialog if they do not perform the same function.
4.1 Testing.
Run Object Inspector. As you position the mouse over objects,
verify that the name, and value fields are available through
Object Inspector. If any fields or blank or have incorrect
information, this checkpoint is not met.
4.2 Positioning related objects.
Position related objects near each other.
4.2 Rationale.
Assistive technologies (screen readers and screen magnifiers)
use proximity to help their users understand the identity and
purpose of objects. Grouping related items makes forms or
dialogs easier to comprehend and execute. In a form where a
customer enters a name and address, you would never think of
placing the State combo box before the Name entry field.
Instead, place the State combo box after the City entry field.
This not only improves accessibility for users with
disabilities, but improves the usability for all users.
4.2 Techniques.
* Group items by function or logical association. For example,
Name, Street, City, and state can be grouped together under
the heading "Address."
* Order elements by their sequence or use. For example, in an
ordering application, group the items in the order they
would be entered.
* Order objects by importance with the most important fields
at the beginning of the group.
* Use sections to organize data into meaningful groups.
4.2 Testing.
Run the application with a screen reader to hear that
information is presented in a logical and meaningful order.
5.1 Option to display audio alerts
Provide an option to display a visual cue for all audio alerts.
5.1 Rationale.
Users may not be able to hear or distinguish sounds if they are
deaf or hard-of-hearing, work in noisy environments, or turn off
sounds to avoid disturbing others. In order for these users
respond to the audio alerts, those alerts must be presented
visually as well. Typical alerts might be the receipt of new
mail, beeps to indicate system errors, or sounds to indicate a
change in status.
5.1 Techniques.
The following techniques can be used to provide visual cues for
audio information.
* System alerts are signaled to a deaf or hard-of-hearing user
with SoundSentry feature in the Windows operating systems.
This provides a generic visual indicator when the software
makes a noise. SoundSentry works reasonably well in cases
where the sound is just a generic beep that is warning the
user or trying to attract his or her attention. For Windows
and other operating systems, SoundSentry requires no special
coding on the part of application developers.
* However, SoundSentry is insufficient for applications that
use different sounds to convey more complex information.
Windows software can check the ShowSounds flag by calling
the SystemParametersInfo function with the SPI_GETSHOWSOUNDS
value, and if set present visual equivalents of all audio
information.
* Flash the title bar of the window which is receiving the
alert. For Windows software, this can be done using the
FlashWindow function. If the window is not visible, flash
the application button on the taskbar to indicate the alert.
* Display a message box for the alert.
* Display a status indicator on the notification area of the
taskbar that flashes when initially displayed to attract the
user's attention.
* Place a text message in a status window.
5.1 Testing.
* If the software has an option to set user preferences,
verify there are options to show audio alerts visually.
* For Windows applications, go to the Sound tab under
Accessibility Options in the Windows Control Panel. Turn on
SoundSentry. Verify that the system provides a visual
warning for system audio alerts.
* For Windows applications, go to the Sound tab under
Accessibility Options in the Windows Control Panel. Turn on
ShowSounds. Verify that the system provides a visual cue for
information provided through auditory output within the
software.
5.2 Visual display of information in audio format
Provide an option to display audio information in text format,
either as closed captioning, a pop-up window or other means, in
parallel and/or in synchrony with the audio content.
5.2 Rationale.
Users may not be able to hear or distinguish sounds if they are
deaf or hard-of-hearing, work in noisy environments, or turn off
sounds to avoid disturbing others.
5.2 Techniques.
* Provide a transcript of the audio which can be displayed
separately, not synchronized with the audio track.
* Provide a pop-up text window for short audio information.
5.2 Testing.
Test the portion of the software which provides auditory output.
Verify the information in the audio is available as text which
is either shown in parallel or in synchrony with the audio.
5.3 Visual display of information in video format
If important information is provided in video format, then the
same information must be provided in an accessible format.
5.3 Rationale.
Users may not be able to hear or distinguish sounds in a video
if they are deaf or hard-of-hearing. If the information is
important, it will need to be provided in another format so that
the user can access the information.
5.3 Techniques.
* Provide a transcript of the video which can be displayed
separately, not synchronized with the audio track.
* Provide a long description of the video.
* Provide a synchronized description of the video.
5.3 Testing.
Test the portion of the software which provides video output.
Verify the information in the video is accessible with a text
description of the video.
5.4 Disable sounds and adjust volume
Provide an option to enable the user to disable sound and adjust
the volume.
5.4 Rationale.
Users may not be able to hear or distinguish sounds at certain
volumes, so they need the ability to adjust the volume.
Sometimes it may be necessary to disable sound to avoid
disturbing others.
5.4 Techniques.
* Windows applications can check the SM_BEEP option using the
GetSystemMetrics function. If this option is FALSE, users
have chosen to turn off the standard system beep, and you
can assume whether they want other sounds turned off as
well.
* Windows applications where sounds are played by calling
PlaySound and specifying a registry-based sound event do not
require additional work to meet this checkpoint. The user
can turn off these sounds by changing the Sound options in
the Control Panel.
5.4 Testing.
Verify your application's sounds respect the system sound
settings or that there are application options to adjust the
volume and turn off sounds (turn volume off).
6.1 Displaying text
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.
6.1 Rationale.
Screen readers attempt to infer what software is doing by
watching calls to drawing functions and remembering what text
and graphics have been drawn and where. Those utilities also
save attributes of the text such as font, size, color, and
style, to be reported to the user. They also watch information
being copied from one location to another and being erased or
overwritten by other text or graphics. The component in a screen
reader that does all this difficult work is called an off-screen
model (OSM). OSM's rely on being able to monitor normal Windows
drawing operations.
6.1 Techniques.
* Draw text using the standard function calls, such as Windows
ExtTextOut, which can be seen by screen readers.
* Use standard functions to copy or erase text and graphics.
For Windows these include BitBlt, PatBlt, and StretchBlt.
You need to do this whether drawing is to a screen or to an
off-screen bitmap, because utilities track the text and
graphics from the time they are drawn until they are copied
to the screen.
* Avoid directly manipulating bitmaps. Some applications
directly manipulate the memory associated with a device
context, bypassing the Windows functions altogether. In
these cases screen readers are not aware of the changes
taking place.
* Avoid directly modifying the screen. The Windows application
programming interface (API) provides several means of
manipulating bitmap or display pixels directly, such as
DirectDraw, Display Control Interface (DCI), WinG, and the
CreateDIBSection function.
* If your application uses any of the non-standard techniques
for performance, you should also use conventional methods
when a screen reader is running. You can determine this by
calling the SystemParametersInfo function with the
SPI_GETSCREENREADER value.
6.1 Testing.
Run the software with a screen reader and verify that all text
in client windows can be spoken.
6.2 Using color to convey information
Ensure that all information conveyed with color is also conveyed
in the absence of color.
6.2 Rationale.
If the software conveys information by color alone, users who
cannot identify or distinguish colors will not be able to make
use of the information. For example, asking users to press the
red button is not useful if they can't distinguish the red
button from other buttons on the screen. The software needs to
provide another way of making the information available.
6.2 Techniques.
* Provide a brief text description of the object.
* Include a graphic/character such as an asterisk by the item
to denote importance.
* Use other attributes, such as bold and/or italic in addition
to color to distinguish text.
6.2 Testing.
* Save screen shots and print on a black and white printer.
Verify that all information is still conveyed.
* For Windows applications, test with a high contrast setting
black on white or white on black.
6.3 High contrast support
Support systems settings for high contrast for all user
interface controls and client area content.
6.3 Rationale.
For many people, color is a matter of preference, but it is
critical for many users with visual impairments. Many people
require a reasonably high contrast between text and the
background to be able to read. They may even need a particular
scheme, such as white text on a black background, to prevent the
background from "bleeding" over and obscuring the foreground
text. Some people consider the default color scheme quite
legible but find that it causes eyestrain over longer periods of
time.
6.3 Techniques.
* For Windows software, use only colors that the user can
customize through the Accessibility Settings for High
Contrast in the Control Panel or through the application's
own view options. Call GetSysColors to identify the colors
chosen through Control Panel.
* Windows software can check for the high contrast setting by
calling the SystemParametersInfo function with the
SPI_GETHIGHCONTRAST value. Applications should query and
support this value during initialization and when processing
WM_COLORCHANGE messages.
6.3 Testing.
For Windows software, turn on the high contrast setting, and
check that your application respects that setting. For example,
if you choose the High Contrast scheme to be "High contrast #1"
(yellow on black) in Windows 98, most window text, including the
main (client, document) window, should be yellow on black. In
this example, title bars and menus have different colors. You
can check the colors of the "High Contrast #1" by choosing that
scheme in the Display settings dialog, Appearance page.
6.4 Inherit system settings for display
Inherit system settings for font, size, and color for all user
interface controls (menus, buttons, dialog boxes, etc.).
6.4 Rationale.
Some people like to fit a maximum amount of information onto a
single screen, but many users have difficulty reading small
text, seeing small objects, or targeting small objects with the
mouse. Therefore you should be flexible when sizing objects on
the screen.
Small fonts cause eye-strain and can make reading difficult or
impossible for many people who do not have disabilities. To
these users, small font sizes represent failed usability. Screen
elements with fixed sizes may also be too small on
high-resolution displays or exceed the screen size on small,
hand-held computers.
When a user specifies system text attributes, your application
must support those.
6.4 Techniques.
* If the application uses standard dialog controls including
menus, then the system font color and size settings will be
respected.
* Windows applications that draw their own screen elements
should pick up the size settings that the user has selected
in the Display settings of the Control Panel. For example, a
private dialog box manager that draws custom dialog boxes
should use the dialog box font that the user has selected
for the rest of the system. The same principle applies for
scroll bars, custom menus, and so on.
6.4 Testing.
Test the application with a scheme with non-standard fonts and
colors.
6.5 Zoom option
Provide a zoom function that allows the user to increase or
decrease magnification of client area content.
6.5 Rationale.
The size of text and graphics affects usability as well as
accessibility. Many individuals who do not consider themselves
to be disabled want to "view" a document or an application work
area in an enlarged font while not affecting the actual document
or work. For individuals with acknowledged visual impairments,
the ability to zoom the application work area to 150%, 200% or
greater may make the difference between being able to use the
application or not. The vast majority of individuals who need
this kind of access do not use screen magnifiers.
6.5 Techniques.
* Provide a zoom option in the View menu to allow flexible
choice of enlarged text. Compare with Microsoft Word or
Lotus 123.
* Zoom features scale everything in the document to a
user-selected ratio. Use of the TrueType scalable font
technology ensures that characters will remain clearly
defined at almost any size.
* Draft mode means providing an option to display all text in
a single font and size. If possible, allow the user to
choose the draft font and size. Use underlining or a similar
form of highlighting to indicate text that should be drawn
with special formatting, such as bold or italics. (Draft
mode also improves performance when running on slow systems
or with little free memory.)
* Wrap to window options are helpful when displaying text
documents. When the user chooses this option, the
application should not break lines on the screen as they
would appear on the printed page, but instead reflow each
paragraph to fit the window.
6.5 Testing.
Test all magnifications of the Zoom option. Verify that the
document is not effected by changing the Zoom setting.
6.6 Turn off backgrounds
Provide the capability for users to turn off patterned
backgrounds behind text or graphics.
6.6 Rationale.
Text drawn over a patterned background will be illegible for
many users because it does not provide sufficient contrast
between the background and the text, and because the pattern
"bleeds" into the text. In order for them to read the
information on the screen, users need to be able to turn off the
background and revert to a solid color background.
6.6 Techniques.
* Provide an option which enables users to turn off the
background in the software.
* Turn off the background in response to the High Contrast
setting.
* Provide sufficient contrast in the default background and
the text. For example, do not use black text on a gray
background.
6.6 Testing.
Verify that any patterned background can be replaced with a
solid background.
7.1 Adjust response time
If timed responses or timed instructions are used by the
software, provide an option to adjust the response time or allow
the instruction to persist. The response time should be
adjustable to at least 5 times the average response time.
7.1 Rationale.
Some users have difficulty reading or responding to information
if it is displayed briefly or requires a quick response time.
Some response delays may also be caused by the use of assistive
technology used to read the screen or in the use of tools which
magnify only a portion of the screen.
7.1 Techniques.
* Provide an option which enables users to adjust response
times or enables instructions to persist.
* Do not have timed responses for important messages. Display
the message until the user closes it.
7.1 Testing.
* Verify that all timed responses can globally be caused to
persist for at least 5 times the average response time.
* Verify that important messages are displayed until dismissed
or until the user has sufficient time to read them.
7.2 Disable screen updates or flashing
Provide an option to either slow down or disable rapid screen
updates or flashing.
7.2 Rationale.
Rapid screen updates can cause epileptic seizures in susceptible
individuals. This includes flashing text or graphics on and off
or repeatedly changing between different images on the screen.
7.2 Techniques.
* Provide an option which enables users to slow down or
disable screen flashing.
* Windows software. Flash information at the caret blink rate
which can be adjusted through the Control Panel. Query this
setting by calling GetCaretBlinkTime.
7.2 Testing.
If the software has rapid screen updates or flashing, then
confirming that there are no such events after the option to
disable those features has been exercised.
8.1 Accessible formats for documentation
Provide documentation in an accessible format, such as ASCII
text or HTML.
8.1 Rationale.
Some users may not be able to access product documentation if it
is not in an accessible format.
8.1 Techniques.
* Provide product documentation on-line in ASCII text or HTML
format.
* Include text descriptions of illustrations (graphics) in the
documentation.
* Provide documentation in an accessible format (braille,
audio cassette) upon request from the user.
8.1 Testing.
Test HTML documentation with one of the test tools suggested in
the relevant sections of the Web Accessibility Checklist.
8.2 Document accessibility features
Provide clear and precise documentation on all accessibility
features.
8.2 Rationale.
People with disabilities cannot effectively use the software if
they cannot access information on how to use accessibility
features. This requirement and checkpoint 1.2 may seem
unnecessary, but software development targets non-disabled
users, and accessibility features may get forgotten when the
product documentation is prepared.
8.2 Techniques.
* Provide accessibility documentation in the product help.
* Include a keyword search and help topic item for
accessibility and/or disability.
* Include a section called "Accessibility" where all
accessibility documentation is provided.
8.2 Testing.
* Open the software documentation. Search on the words
"accessibility" or "disability".
* If the product provides "how to" instructions and pop-up
help, verify they include instructions for performing the
actions using the keyboard in addition to using the mouse.
Object Inspector
Object Inspector is an application provided by Microsoft as part
of the Software Development Kit (SDK) for Active Accessibility.
Inspector can be used to validate the aspects of accessibility
of software user interface elements which use Microsoft Active
Accessibility (MSAA) or standard windows controls. It supports
software written for the Windows 9x, Windows NT or Windows 2000
platforms. Object Inspector can be downloaded as part of the
Microsoft Active Accessibility SDK. There is no charge to
download and use the SDK.
Once the SDK has been installed, go to the Program Menu, select
Microsoft Active Accessibility SDK and then Inspect Objects.
When Object Inspector is loaded, it displays information about
the properties of an object as you select the object with the
keyboard or move the mouse over the object. If the software uses
Windows standard controls, or if the controls are non-standard
and MSAA has been implemented, Inspector will report the
information. If the software uses custom controls which are not
exposed through MSAA, the properties will be blank and that is a
failure for accessibility. The following properties may be
exposed by the application.
* Name - a string used to identify, find or announce an object
(e.g., text on a button or tab, prompt on an entry field)
* Role - describes what kind of user interface element an
object is (e.g., push button. radio button, check box, combo
box, edit box, page tab).
* State - describes an object's status at a moment in time
(e.g., selected, focused, selectable, unavailable, checked,
unchecked)
* Value - represents information contained by the object. For
example, the value for a link is the URL for the link, the
value of an edit field is the text in contains (if any), and
the value of a combobox is the selected item (if any).
* Description - provides a textual description about an
object's visual appearance.
* Help - provides information that tells the user about an
object's function. This is typically used for balloon style
information (e.g. ToolTips).
* KeyboardShortcut - describes a key or key combination that
will activate a specified object.
* DefaultAction - describes the object's primary method of
manipulation.
The graphic below shows a screen shot of Object Inspector where
focus is on a button.
For a selectable control, the important properties are Name,
Role and State. The value of the Name property is "Yes" because
that is the button label. The Role property identifies the type
of control, which in this case is a push button. The value of
the State property is "Normal" because the button is not
selected.
Using Object Inspector to verify selectable controls (e.g.,
radio buttons, check boxes, push buttons)
Selectable controls are accessible if they meet the following
criteria when testing with Object Inspector.
If any of the following fields are blank, the software is not
accessible.
* Name: The name associated with the control. For example, in
Notes Mail, there is a checkbox to identify confidential
memos. The value of the Name property should be IBM
Confidential.
* Role: The type of control (radio button, check box, push
button).
* State: The state should be one or more of the following as
appropriate - checked, unchecked, default (to indicate
default push button), normal, focused, focusable,
unavailable.
Using Object Inspector to verify graphics
Graphics are accessible if they meet the following criteria when
testing with Object Inspector.
If any of the following fields are blank for important graphics,
the software is not accessible.
* Name: Text which describes the graphic.
* Role: The type of control (graphic, link).
* State: The state should be one of the following as
appropriate - focusable, selectable, focused.
* Value: The value of the URL for graphic links.
Using Object Inspector to verify edit controls
The following fields must be present as indicated.
* Name: The static label of the edit field.
* Role: The type of control, "editable text."
* State: The state should be one of the following as
appropriate - focusable, selectable, focused.
* Value: The text contained in the edit field.
Magnifier
Magnifier is a Windows tool which allows you to magnify a
portion of the screen which is then displayed in a separate
magnifier window. Magnifier tracks the focus so it can
automatically keep the active area in the magnifier window.
Magnifier is available from Microsoft as part of the Software
Development Kit (SDK) for Microsoft Active Accessibility. When
you install the SDK, Magnifier will also be installed. To run
Magnifier from the SDK, go to the Start menu and select
Programs, Microsoft Active Accessibility SDK and then Magnifier.
If you are running on Windows 98 or Windows 2000, you can also
load Magnifier by going to the Start menu and selecting
Programs, Accessories, Accessibility, and then Magnifier.
When you start Magnifier, verify the following options are
selected:
* Follow mouse cursor
* Follow keyboard focus
* Follow text editing
* Show magnifier
Microsoft Active Accessibility (MSAA)
MicrosoftrActive Accessibilityr is a developer technology that
improves the way programs and the operating system work with
assistive technology. Using Active Accessibility, software
developers can make their programs more compatible with
assistive technology, and assistive technology developers can
make more reliable and more robust tools. You can find out more
about MSAA by visiting
http://www.microsoft.com/enable/msaa/default.htm
Screen Readers
Someone who is blind requires a screen reader to use a computer.
A screen reader makes information on the screen available as
synthesized speech or a refreshable braille display. Screen
readers can translate text information or graphics which have
alternate text describing the images. The ability of the screen
reader to read the software depends on the software's use of
standard operating system controls or accessibility APIs such as
Microsoft Active Accessibility (MSAA) for the Windows
environment.
Henter-Joyce offers a free demonstration copy or a timed
evaluation copy of JAWS for Windowsr on their web site at
http://www.hj.com/. The free demo is fully functional for 40
minutes each time you start a new Windows session, and includes
the Eloquence for JFW speech synthesizer. The timed evaluation
copy is available for a nominal fee and runs for 60 days.
GW Micro offers a free demonstration copy of Window-Eyesr on
their web site at http://www.gwmicro.com/. The free demo is
fully functional for 30 minutes each time you start a new
Windows session. You have to restart Windows to continue to use
Window-Eyes for another 30 minutes.
References and resources
"EITACC Desktop Software standards":
Electronic Information Technology Access Advisory
(EITACC) Committee.
trace.wisc.edu/docs/eitacc_desktop_software_standards/
desktop_software_standards.htm
"Requirements for Accessible Software Design":
US Department of Education, version 1.1 March 6, 1997.
ocfo.ed.gov/coninfo/clibrary/software.htm.
"Java accessibility guidelines and checklist":
IBM Special Needs Systems. This site contains detailed
guidelines for the Java environment.
"Windows accessibility guidelines":
Microsoft. 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. This site contains detailed
guidelines for the Web and HTML.
"Lotus Notes accessibility guidelines":
IBM Special Needs Systems.This site contains detailed
guidelines for accessible Lotus Notes applications.
"What is Accessible Software":
James W. Thatcher, Ph.D., IBM, 1997. The paper discusses
problems encountered by computer users who have
disabilities and what developers can do to make their
software accessible.
"Making the GUI Talk":
Richard S. Schwerdtfeger, IBM, 1993.
ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt. This
paper discusses "Off-Screen Model" technology and GUI
Screen Readers.
"Towards Accessible Human-Computer Interaction":
Eric Bergman, Earl Johnson, Sun Microsytems 1995.
www.sun.com/tech/access/updt.HCI.advance.html. This
paper discusses accessible user interfaces.
----------
>From the web page
http://www.austin.ibm.com/sns/accessweb.html
Web accessibility
Follow this checklist to make your Web site accessible. This
list has been updated and includes some of the latest quick tips
and guidelines from the W3C Web Accessibility Initiative found
at www.w3.org/WAI.
Table of Contents:
Checklist for Web accessibility
Rationale, Techniques, Testing
References and resources
Checklist for Web Accessibility
IBM Web Accessibility Checklist - Version 2.1
January 11, 2000
Rationale, Techniques and Testing
1. Images and animations
Use the alt=3D"text" attribute to provide text equivalents for
visuals. Use alt=3D"" for visuals that do not convey important
information or convey redundant information.
1. Rationale
Text browsers and screen readers cannot convey images to their
users. To compensate, it is important to associate alternative
text with all images, especially for active images, i.e., images
which are links or buttons. The alternative text should be
meaningful, like "home page" or "search" or "products." When
images are not links, use alternative text carefully. A person
having to listen to a page cannot ignore text the way a person
viewing the page can ignore an image. If images are not
important or if they are redundant, use alt=3D"", telling the text
browser to ignore the image.
The use of alternative text is not just for people who are
blind; alternative text is also used by voice recognition
software. Links which are images are not accessible to voice
recognition software unless the author has provided alt text for
the image. The user, navigating the Web with voice recognition,
can say "click home page" for the image whose alternative text
is "home page."
1. Techniques
Each IMG and AREA element must have an alt attribute. If the IMG
is not a link, and it is not important, use alt=3D"".
Often navigation links are presented as images. The ideal
alternative text in this case is exactly the word or words
contained in the image. If the text on the graphic is
"solutions", then don't use "click here to go to the solutions
page" for the alt text. Use "solutions" just as it is seen in
the graphical browser.
Use alternative text for all AREA's in an image map. When the
mouse is passed over the client-side image map, these
alternative text entries will appear as text pop-ups.
Image buttons need alternative text as in the following example.
=
1. Testing
* The alternative text for each image is displayed as a text
pop-up when the mouse is held over the image. If an image is
important and no text pop-up appears, the image needs
alternative text. Unimportant or redundant images should be
tagged with alt=3D"" and nothing will pop-up when the mouse is
held over the image.
* If you turn off images in your browser each image will be
replaced with its alternative text. This is a good testing
technique for a quick text view of a page. It will be obvious
which graphics are not labeled. Microsoft Internet Explorer 5
works best for this test.
* When you view a page with IBM Home Page Reader, all the links
are in the Links List down the left. Make sure the text for each
link is meaningful and succint. If you see links in square
brackets with the word "Link" or "Map" ([Link:
http://www.ibm.com] or [Map: http://www.ibm.com/sns]), these
image links lack alternative text. HPR has inserted some part of
the URL because the alternative text is missing.
* Test the site with Bobby. Bobby will list all the images that
lack alternative text.
2. Image Maps
Use client-side image maps to provide accessible text for image
map hot spots. If you use server-side maps, provide equivalent
text links.
2. Rationale
Server-side image maps are not accessible to anyone using a text
browser or a browser with images turned off.
Client-side image maps are accessible to text browsers when the
alternative text is supplied for the map image and for each area
of the map. Refer to Checkpoint 1.
2. Techniques
If you must use a server-side map, then include a list of
equivalent text links, one for each URL that can be activated
through the map. For example, a map of the United States as a
server-side map would need a list of the individual states or
other alternative method of choosing a state. You could put link
text that said, "choose the state" next to the map. The
important thing is that the equivalent links be as convenient as
the server-side map for the user.
Use client-side image maps with alt text.
Server-side Image Maps
Provide a list of text links when using a server-side image map.
The list of text links would be phrases representing the
clickable regions on the image.
For Example: If you had an image of a world map, where each
country boundry region was a hyperlink, you would also need to
list each of the countries as hypertext links.
Austria | Australia | etc.
Belgium | Belieze | etc.
USA | etc.
2. Testing
* Home Page Reader will indicate a server-side map like this:
"[Server Side Map: Sports]" (from the Washington Post). If
there is a server side map, the equivalent text links must
be present. Image areas of client-side maps that don't have
alternative text show up like this: [Map: subst/home/home].
* Test the site with Bobby. If you have a server-side map,
that accessibility error will be the first Priority 1 item,
"Provide redundant text links for all server-side image map
hot-spots. (N instances)" in the Bobby report. Map areas
without alternative text show up in the list of images
without alternative text.
3. Graphs and Charts
Summarize the content of each graph and chart or use the
longdesc attribute to link to the description or data.
3. Rationale
A chart or graph is essentially an image with detailed
information. Text browsers and screen readers cannot convey
images to their users, so you need to provide a text equivalent
of the graphical information.
3. Techniques
Use one of the following three techniques for this checkpoint.
All three are illustrated in the example that follows.
* Include the description in the flowed text.
* Use a "D-Link" with a URL containing the description.
* Use the long description attribute, longdesc=3D"longd.html"
D
This chart shows the percentage of cars and trucks out of the
total vehicles passing through a toll booth in one hour.
Seventy-five percent of the vehicles were cars; twenty-five
percent of the vehicles were trucks.
3. Testing
All images should have alternative text per Checkpoint 1. The
only way to check for descriptions is to view all pages or check
the list of images that your authoring tool provides. Make sure
charts and graphs are described in line, through a D link, or
with a longdesc attribute on the image.
4. Multimedia
Provide captions or transcripts of important audio content.
Provide text or audio descriptions of important video content.
4. Rationale
For those who are deaf, or hard of hearing, audio content is not
accessible. Videos without descriptions are not accessible to
the blind. In both cases the information needs to be provided in
an alternative format. Important information contained in audio
or video also needs to be available in text.
4. Techniques
A transcript is a word-for-word textual version of the audio.
The user should be given the choice of reading the transcript or
listening to the audio.
The "description" is longer and more significant than the
"transcript". The "audio description" needs to be available in
text form. The video description should be available in both
text and audio form. The description can be both subjective and
artistic, depending on the intentions of the author. This
information is generally available at the beginning of the
creation process and should be retained and made available on
the Web along with the clip.
It may not be necessary to describe "earcons" or "soundcons"
(audio clips) that are associated with bullets, headrules,
backgrounds, etc. unless the author feels it is important to
capture that information and provide it to the user.
See the CPB/WGBH National Center for Accessible Media (NCAM) Web
site for examples.
The descriptions and transcripts can be on the same page, on a
separate page, or on a page with a listing of the descriptions
of all significant clips on that site. The current convention is
to place a hyperlink to the transcript and description near the
clip itself.
4. Testing
Manually search for all audio and video objects. Check that text
equivalents are provided for important video and audio.
5. Scripts, Applets, and Plug-ins
Where possible, provide alternate content for scripts, applets,
and plug-ins so important information is not lost when those
features are unsupported or turned off.
5. Rationale
None of the text browsers, like IBM Home Page Reader or Lynx,
support JavaScript. When you require script execution, users of
those browsers will not be able to access your page. JavaScript
that changes highlighting or fonts is not an issue for
accessibility unless the information conveyed in the mouseover
is necessary to understand or navigate the Web site.
Applets and Plug-ins are not currently supported by the text
browsers or IBM Home Page Reader. However, you can make applets
directly accessible; refer to IBM's Java accessibility for more
information.
5. Techniques
JavaScript
Try to ensure that links that trigger scripts work when scripts
are turned off or not supported. For example, do not use
"javascript:" as the link target. If it is not possible to make
the page usable without scripts, you may be able to provide a
text equivalent with the NOSCRIPT element, use a server-side
script instead of a client-side script, or provide an
alternative accessible page.
Avoid creating content on the client through scripting. If a
user's browser does not handle scripts, no content will be
generated or displayed. Refer to the W3C documentation on
JavaScript for further details.
Applets and Plug-Ins
Provide alt text for Applets.
If the OBJECT element is used, provide a text equivalent in the
content of the element.
5. Testing
Test your page with applets and scripts turned off in your
browser.
* In Netscape go to Edit/Preferences/Advanced to turn off
JavaScript and Java Applets.
* With Internet Explorer choose Tools/Internet
Options/Security to turn off scripts and applets.
If you have not used the NOSCRIPT element or provided a text
equivalent for JavaScript, the page will be broken or unusable.
If you did not make the applet directly accessible or provide
alt text, you will see no content where the applet should appear.
6. Forms
Associate labels with form elements.
6. Rationale
For general ease of use it is important for the labels, like
"Last Name," to be clearly and programmatically linked with the
corresponding form element, in this case an text input field.
When the labels are explicitly associated with the form elements
through HTML markup, assistive technologies can present the Web
author's intention to a person who is blind.
6. Techniques
Some form controls, such as submit buttons, automatically have
labels associated with them, but most do not (text fields,
checkboxes and radio buttons, and menus). If a label is
immediately to the left of a form control or immediately above
the element, then assistive technology will usually be able to
convey the intent as conveyed by proximity. HTML 4 provides
specific markup, the LABEL element, to connect the form element
and its label.
Here is a form with two input fields and two buttons.
Name
<___>
Address
<___>
Here is the HTML for this form in which the input fields are
programmatically connected with the corresponding label.
The following markup for the LABEL element groups the form
control with the label and is equivalent to that above.
6. Testing
Test your form using Home Page Reader's "Where Am I" command
(plus then 5). HPR will announce the label of a text input field.
7. Skip to main content.
Provide methods for skipping over navigation links to get to
main part of a page.
7. Rationale
When a navigation bar appears at the top of a page and/or down
the left side of the page, users who are reading the page with
speech synthesis will have to listen to all of those links
across the top and down the left for each page they visit at the
site before they get to the main content. However, users who are
sighted ignore the links and go right to the main content. The
purpose of this checkpoint is to fix this inequity.
7. Techniques
Here are the methods that you can use to allow users to quickly
bypass groups of links (navigation bars, table of contents,
etc.) to get to other portions of a page.
* The cleanest method is illustrated on the IBM Special Needs
Systems pages. At the top of the page is a link attached to
an unimportant image, and the target of that link is the
beginning of the main content. The alternative text for the
image is "skip navigation links." So a person a using speech
synthesis can activate the link associated with the alt text
and skip down to the main content of the page.
...
The main content...
The target can easily be part of a template, as it does not
have to be associated with text content.
* A simple alternative to the first technique is to display
the "skip navigation" link at the top of the page. This is
illustrated at the American Council of the Blind (ACB) site.
ACB was the first to use this technique.
* If all navigation links are in client-side image maps with
good alternative text on the areas then by default, IBM Home
Page Reader will skip the areas, with an announcement like
"Map, skipping 10 items." Of course the user can stop and
step through the map areas. So using Home Page Reader, image
map areas are skipped automatically.
* You may have several sections of main content. A variation
on the first technique above is to have a series of links
attached to unimportant graphics, for example, "skip to
headlines," "skip to sports," and "skip to business."
* Use headings. If the main content is under the first
heading, then the assistive technology can jump to that
heading.
7. Testing
Test the site with IBM Home Page Reader. Try to get to main
content. If your site is using templates, ensure that the
templates implement the first of the techniques above.
8. Frames
Provide a title for each frame so that users can track frames by
title.
8. Rationale
When people who use text browsers like Home Page Reader and Lynx
visit a FRAMESET page, they must choose which Frame to open. The
choice is given with a list of the Frames. If Web authors
provide meaningful information in their markup, then those users
can make intelligent choices.
8. Techniques
There are two parts to the technique for addressing the frame
navigation problem. First there should be meaningful titles on
each Frame page (the src of each FRAME element). The second part
of a solution is to provide a meaningful name attribute and
title attribute for each FRAME element.
A simple frameset document
As an example of frame navigation, here is what Lynx presents
for the five frames of one page; Lynx displays the frames names
using the NAME attribute on each FRAME element.
FRAME: company logo
FRAME: navigation
FRAME: main contents
Home Page Reader opens each frame page and inserts the page
title, if it is available. If the title is not available, the
name attribute is listed.
[Frame 1 (company logo): Untitled]
[Frame 2: Navigation for the company Web site]
[Frame 3: Main contents for company Web site]
In this example, Frame 2 and 3 get there information from the
TITLE element from navigation.html and maincontent.html. Frame 1
has taken the name attribute of the FRAME element because
logo.html is untitled.
8. Testing
Check that every FRAME element has a meaningful name and title
attribute. Check that each frame page has a meaningful title in
the TITLE element.
9. Tables
Where appropriate, use the CAPTION element and/or the summary
attribute for tabular data. Use the headers attribute on cells.
9. Rationale
If you have normal vision, you can quickly scan through a table
and get a general idea about the data it presents. The purpose
of the CAPTION element and the summary attribute on the TABLE
element is to provide the same kind of information to a person
who is blind or has low vision.
If you can see a TV listing (table), you have the ability to
scan up a column and across a row to find the station and time
of a program. If you cannot see the table, but are listening to
it with speech synthesis, it can be a daunting task to try to
find this simple information. The headers attribute provides one
solution to this problem.
9. Techniques.
The CAPTION element provides a technique for displaying a title
for a table. The summary attribute on the TABLE element provides
a description of the contents of the table. Here is a sample
table:
Cups of coffee consumed by each Senator
Name Cups Type of Coffee Sugar?
T. Sexton 10 Espresso No
J. Dinnen 5 Decaf Yes
The markup for this table follows.
Cups of coffee consumed by each Senator
Name
Cups
Type of Coffee
Sugar?
T. Sexton
10
Espresso
No
J. Dinnen
5
Decaf
Yes
The content of the CAPTION element is displayed, but the summary
is not. An assistive technology browser, like Home Page Reader,
will offer that summary to its user. This provides the kind of
information a sighted user can obtain by looking at the table.
The TH element creates a heading style in the rendered table.
The heading cell has an ID attribute. In the data cells, the
headers attribute specifies the data to be taken as headers for
the cell. For example, the cell with "10" in it has headers=3D"t2"
and the cell with id=3D"t2" has "Cups" in it. So the header for
"10" is "Cups."
The headers attribution can be more complicated. For example the
same table could contain the following markup
T. Sexton
10
In this case the heading for "10" would be "T. Sexton Cups"
since the contents of name1 is "T. Sexton", and the contents of
t2 is "cups".
9. Testing
Check the web site for tabular data, and make sure that those
tables meet this checkpoint. Using Bobby, you can obtain a list
of the TABLE elements in the site. With IBM Home Page Reader,
the table summary is announced in response to the whereAmI
request. Headers are announced as the cells are traversed.
10. Correct Markup
Do not use structural markup, such as headings and lists, for
visual presentation effects.
10. Rationale
Using markup improperly hinders accessibility. Misusing markup
for a presentation effect, such as using a table for layout or a
header to change the font size, makes it difficult for users
with specialized software to understand the organization of the
page or to navigate through it. Using presentation markup rather
than structural markup to convey structure makes it difficult to
render a page intelligibly to other devices. For example, you
should not construct what looks like a table of data with an
HTML PRE element.
You may be tempted to use or misuse constructs that achieve a
desired formatting effect on older browsers, but be aware that
these practices cause accessibility problems. Consider whether
the formatting effect is so critical as to warrant making the
document inaccessible to some users.
At the other extreme,you must not sacrifice appropriate markup
because a certain browser or assistive technology does not
process it correctly. For example, it is appropriate to use the
TABLE element in HTML to mark up tabular information even though
some older screen readers may not handle side-by-side text
correctly (refer to checkpoint 9). Using TABLE correctly makes
it possible for software to render tables other than as
two-dimensional grids.
10. Techniques
Use header elements to convey logical structure and use them
according to specification. For example, in HTML, use H2 to
indicate a subsection of H1. Do not use headers for bold or font
effects.
Use list elements to convey lists of information properly. For
example, in HTML, nest OL, UL, and DL lists as specified. Do not
use list elements for visual indentation formatting effects.
Use quote elements for quotations. For example, in HTML, use the
Q and BLOCKQUOTE elements to markup short and longer quotations,
respectively. Do not use quotation markup for visual indentation.
Refer also to the Techniques for Web Content Accessibility
Guidelines section on "Document structure and metadata"
http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#document
10. Testing
Check your HTML markup. Are you following the proper structural
coding?
11. Cascading Style Sheets
Control presentation and layout with style sheets (CSS) rather
than presentation elements and attributes.
11. Rationale
>From the W3C Web Accessibility Content Guidelines Guideline 3:
Cascading Style Sheets describe how documents are presented on
screens, in print, or perhaps how they are pronounced or
brailled. Style Sheets is a elegantly designed yet simple
mechanism for adding style (e.g. fonts, colors, spacing) to Web
documents. By attaching style sheets to structured (e.g. HTML)
documents on the Web, authors and users can influence the
presentation of documents without sacrificing
device-independence or adding new HTML tags. CSS is one of the
greatest hopes for separation of presentation from content.
The Web is the ultimate cross-platform system, and your content
will be presented on such a huge variety of devices that source
pages should specify the meaning of the information and leave
presentation details to a merger (or "cascade") of
site-specified style sheets and user's preferences. If the
introduction of WebTV or "accessibility" or audio browsers broke
your pages, you will appreciate the ability to introduce new
page designs by creating a single style sheet file rather than
by modifying thousands of content pages.
Style sheets have been an activity since the World Wide Web
Consortium (W3C) was founded and have resulted in the
development of CSS1. For background and tutorial information on
style sheets, see the Web style sheets resource page.
11. Techniques
Use style sheets to control layout and presentation. For
example, use the CSS 'font' property instead of the HTML FONT
element to control font styles.
Refer also to CSS2 ( Cascading Style Sheets), which allows
content developers to duplicate almost every HTML 4.0
presentation feature and offer more power with less cost.
However, until most users have browsers that support style
sheets, not every presentation idiom may be expressed
satisfactorily with style sheets.
In the W3C Techniques for Web Content Accessibility Guidelines
CSS section, it is shown how style sheets may be used to create
accessible pages. Examples are also provided of how to use HTML
4.0 features (e.g., tables, bitmap text) more accessibly when
they must be used.
11. Testing
There is no true test for style sheets.
12. Hypertext Links
Use descriptive link text, not just "click here." Ensure that
each link makes sense when it is read out of context.
12. Rationale
Users of the Web who are blind will often scan through a list of
links in a document to understand the layout and options on the
page. Links that say "go" or "click here" do not make sense out
of context.
12. Techniques
Link text should be descriptive, more than "click" or "here",
without being so wordy that it interferes with efficient
browsing. Several browsers for voice navigation, as well as
screen readers, now list the links separately. All links should
make sense out of context.
Instead of writing,
To return to checkpoint click here.
Make "return to checkpoint" the link.
12. Testing
Screen Readers such as Jaws For Windows (JFW) and Window-Eyes
provide lists of links. Home Page Reader also has a links list.
Authoring tools often provide links lists. With any of these
methods, examine the links to be sure that they make sense and
are not too verbose.
Appendix
The appendix expands on some of the earlier instruction on
testing using IBM Home Page Reader, Microsoft Internet Explorer
5.0, and Bobby.
Microsoft Internet Explorer 5.0
You can obtain Internet Explorer 5.0 from the Microsoft's IE5
site. To turn off images,
* Select Tools - Internet Options - Advanced.
* Select "Always expand alternative text for images."
* In the multimedia section deselect "Show pictures."
IBM Home Page Reader
IBM Home Page Reader is designed for people who are blind or
have severely low vision. This explanation is for people with
normal sight who want to test Web sites for accessibility. It is
not necessary for such a person to learn all the key
combinations, settings and navigation strategies if you can see
the HPR display and the Netscape windows.
A full function thirty day trial version of IBM Home Page Reader
(HPR) is available at the IBM Special Needs Systems web site.
The Home Page Reader product can be purchased at ShopIBM. People
who are employed by IBM can find Home Page Reader on the IBM
internal Special Needs web site.
The Stop button stops speech. Listen to the page with Play. If
the speed of the speech is too slow, you can always increase it
using the Rate slider on the left of the control window.
The fundamental test for accessibility is whether all the
information available visually in Netscape or Internet Explorer
is also available in text in HPR. You can listen to each page
and hear what a blind person hears. When alternative text on
images is missing or cumbersome, it will be obvious. In its
default settings, HPR speaks all active elements, including
links and control elements, in a female voice.
Instead of listening to every word on the page, you can examine
the HPR text view (the Contents window). HPR provides
information which will help you to make the page easier for all
to use while you make it more accessible. Information from the
page which is not displayed in the Netscape or Internet Explorer
graphical view is enclosed in square brackets. Meta-information
added by Home Page Reader is enclosed in parentheses.
The Location Text Field
Enter a URL for a page to be spoken. The URL of the current page
is displayed here.
The Links List
The Links List window lists all the links in the current page.
Double click on a link to follow it. As soon as you load a page
HPR starts talking. As you listen to the page, the current link
is highlighted and spoken in a female voice. The items in square
brackets are image links. The text in each case is the
alternative text and should be both meaningful and succinct.
The History List
If you resize (enlarge) the main window on the right, a history
list will be displayed in the top right corner. This is the list
of previously visited pages. The current page is highlighted. To
return to any page, just double click the page you want.
The Contents Text Area
The text version of the current page is displayed here. As the
page is spoken, the current paragraph (item) is highlighted and
then words are "unhighlighted" after each is spoken.
As you move the caret around the contents window, lines, words,
or characters will be spoken. As active elements are spoken, the
corresponding link in the Links List is highlighted.
Just as in the Links List, text that is not rendered in the
graphical browser is placed inside square brackets. This is
alternative text for images and image links. In the case of
links, if there is no alternative text, then some substring of
the target URL is placed in the brackets instead.
The text in parentheses is called "meta text." It alerts the
reader to the beginning of forms and select menus. The HPR
search function includes the ability to search for meta text.
The Control Area
Several controls have already been mentioned (Play, Stop, and
Rate).
Back opens the previous page in the history list. Next opens the
next page. Reload reloads the current page.
Bookmark opens the HPR bookmark page. Add Bookmark places the
current URL at the bottom of the bookmark page.
When Auto Sync is checked, the page loaded in HPR will be
displayed in Netscape. Conversely, if you load a page in
Netscape it will be spoken by HPR.
When Auto Sync is not checked, you can use the Speak Browser
button to have the Netscape page rendered in HPR and the Show
HPR button to have the HPR page displayed in Netscape.
The Volume slider changes volume.
Speaking an item at a time
You can step through the entire page using the the next item
key, 6 on the numeric keypad. Previous item is 4, and current
item is 5.
Saving the current page
You may want to save the text view of the page to a file. Bring
up the Text Entry Dialog with Plus then Dot on the numeric
keypad. Type > (for redirect) and a file designation, for
example,
>C:\docs\mysite.txt
This will save the file as a text file (mysite.txt in this
case). If the extension is .htm, the file will be saved as an
html file.
Searching
To search in the text view, bring up the input dialog with Plus
then Dot. Enter a forward slash and the text, e.g.,
/New Releases
HPR will search for "New Releases" in the text content window.
The search is not case sensitive. You can continue searching
with the chord, enter with 6, on the numeric keypad. Enter with
4 searches backwards.
Bobby
Bobby is a tool for analyzing web pages for accessibility and
conformity to HTML specifications. It has been developed by the
Center for Applied Special Technology
Bobby comes in two flavors. With the Web version of Bobby you
insert a URL for an internet page, and obtain a Bobby report
on-line.
Alternatively you can download Bobby and use the tool on web
pages under development.
References and resources
"IBM Home Page Reader:
IBM Special Needs Systems.
http://www.austin.ibm.com/sns/hpr.html. IBM's talking
Web browser for blind and visually impaired users.
"Java accessibility guidelines and checklist":
IBM Special Needs Systems.
www.austin.ibm.com/sns/accessjava.html. This site
contains detail guidelines for the Java environment.
"Software accessibility guidelines":
IBM Special Needs Systems.
www.austin.ibm.com/sns/accesssoftware.html. This site
contains general software guidelines.
"Towards Accessible Human-Computer Interaction":
Eric Bergman, Earl Johnson, Sun Microsystems, 1995.
www.sun.com/tech/access/updt.HCI.advance.html. This
paper discusses accessible user interfaces.
"Experiences Implementing Web Accessibility Guidelines in
IBM":
Phill Jenkins, IBM, 1997.
www.austin.ibm.com/sns/phillj.htm. This paper covers
disabilities issues and older general accessibility
guidelines.
"Web Content Accessibility Guidelines":
World Wide Web Consortium (W3C), 1999.
http://www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth.html.
These guidelines cover the responsibilities of the
content author.
"List of Checkpoints for the Web Content Accessibility
Guidelines":
World Wide Web Consortium (W3C), 1999.
www.w3.org/TR/WAI-WEBCONTENT/full-checklist.html. A
checklist for Web content developers. Each checkpoint in
the guidelines appears in this list, organized by
priority and concept.
"Techniques for Web Content Accessibility Guidelines":
World Wide Web Consortium (W3C), 1999.
www.w3.org/TR/WAI-WEBCONTENT/wai-pageauth-tech.html.
This document includes techniques and examples that HTML
and CSS authors may use to implement the guidelines and
meet the checkpoints described in "Web Content
Accessibility Guidelines".
"User Agent Accessibility Guidelines":
World Wide Web Consortium (W3C), 1999.
www.w3.org/TR/WD-WAI-USERAGENT/. These guidelines cover
the responsibilities of the browsers.
"Authoring Tools Accessibility Guidelines":
World Wide Web Consortium (W3C), 1999.
www.w3.org/TR/WD-WAI-AUTOOLS/. This document provides
guidelines to Web authoring tool manufacturers or
developers. The purpose of this document is two-fold: to
assist developers in designing authoring tools that
generate accessible Web content and to assist developers
in creating an accessible authoring tool user interface.
----------
>From the web page
http://www.austin.ibm.com/sns/accessjava.html
Java tm accessibility
IBM Special Needs Systems and Sun Microsystems' accessibility
group have combined efforts to design and build next-generation
accessibility into Java. IBM issued a press release about
bringing the power of Java to users with disabilities. Learn
more about the accessibility issues being addressed and read the
accessibility article featured on IBM's Java site. Read how IBM
is focusing on the Java platform for accessibility and how Java
can speak using the Self Voicing Kit (text-only SVK site), which
is IBM's solution to bring cross-platform accessibility to
mainstream computing.
Table of contents:
Checklist for accessible Java applications
Java accessibility guidelines
References and resources.
Checklist for accessible Java applications
Follow this checklist to make your Java application accessible.
For anyone developing graphical Java applications it is important
that you follow this checklist. In the follow-on guidelines
section, detailed examples are shown on how to write accessible
Java applications using the Java Foundation Classes (JFC/Swing)
and the Java Accessibility API.
Java accessibility checklist - version 2.1
January 11, 2000
1
User interface components.
1.1
Use the Java Foundation Classes (JFC) / Swing components or
implement the Java Accessibility API.
1.2
Follow the guidelines when extending the Java Foundation
Classes/Swing components.
1.3
Follow the guidelines to implement the Java Accessibility API on
custom components.
2
Essential programming practices.
2.1
Enable keyboard access (operable without the mouse).
2.2
Describe icons and graphics and set AccessibleDescriptions on all
components.
2.3
Set the focus.
2.4
Label components.
2.5
Be multi-threaded so an assistive technology can also run.
2.6
Name logical groups.
2.7
Provide a logical layout.
3
Documentation.
3.1
Provide documentation in an accessible format such as ASCII text
or HTML.
3.2
Provide documentation on all accessibility features as part of
the regular product documentation.
4
Verify accessibility.
4.1
Test for accessibility using "assistive technology" (i.e., IBM
Self Voicing Kit technology for Java available from
http://www.alphaWorks.ibm.com).
Java accessibility guidelines
The "IBM Guidelines for Writing Accessible Applications Using
100% Pure Java" are available as a complete document. This is the
industry's first set of 100% Pure Java application development
guidelines for accessibility. A brief outline of the contents is
included here to give you an overview of the information:
* 1.0 Executive Summary
* 2.0 Introduction
o 2.1 Disability Issues
o 2.2 Why Java for Accessibility?
* 3.0 Essential Accessibility Programming Practices.
You will find a list of specific practices that are absolutely
essential in order to make your Java application usable by
persons who have disabilities.
* 4.0 Java Foundation Classes (JFC) - A Foundation for
Accessibility
This section discusses the huge advantages of using the JFC to
provide accessibility.
* 5.0 Using JFC to Build Accessible Applications
Read this section to find out specifics about using the JFC to
incorporate accessibility features in your applications. The
section includes the following topics:
o Setting up the JFC Development Environment
o Using the JFC Components unmodified
o Enhancing JTextComponents
o Changing Data Models and Cell Renderers
o Creating new Components based on the JFC
o Preparing for Future JFC Accessibility Features
* 6.0 The Accessibility API
This section defines the Accessibility API. If you don't use the
JFC, you can implement the Accessibility API to ensure that your
application is accessible. The API allows assistive technology
software to extract information from your components. Note: The
Accessibility API is now shipped with the JFC package and can be
found in the com.sun.java.accessibility package. It is scheduled
to be integrated into JDK 1.2
* 8.0 Testing for Accessibility
Includes a checklist on how to use the test tool features of
IBM's Self Voicing Kit (SVK) to test your application for
accessibility.
* 9.0 Online Information and Help
When developing documentation for your application in HTML please
follow the comprehensive Web accessibility guidelines.
* 11.0 Appendix
The appendix contains the suggested keyboard bindings and a list
of accessibility references.
References and resources
"Software accessibility guidelines and checklist":
IBM Special Needs Systems. This site contains the software
guidelines and a checklist.
"Windows accessibility guidelines":
Microsoft. 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. This site contains detailed guidelines
for the Web and HTML.
"Towards Accessible Human-Computer Interaction":
Eric Bergman, Earl Johnson, Sun Microsystems, 1995.
www.sun.com/tech/access/updt.HCI.advance.html. This paper covers
accessible user interfaces.
"Making the GUI Talk":
Richard S. Schwerdtfeger, IBM.
ftp://ftp.software.ibm.com/sns/sr-os2/sr2doc/guitalk.txt
Off-Screen Model Technology and GUI Screen Readers
"Accessibility Quick Reference Guide":
Sun Microsystems. www.sun.com/tech/access/access.quick.ref.html.
"Java Development Kit":
Sun Microsystems. java.sun.com/products/jdk/.
"Java Foundation Classes (JFC/Swing)":
Sun Microsystems. java.sun.com/products/jfc/.
----------
>From the web page
http://www.austin.ibm.com/sns/accessnotes.html
Lotus Notes accessibility
These guidelines are provided to help make your Lotus Notes
applications accessible to everyone. Some features in Lotus
Notes 4.x are not accessible to people with disabilities (e.g.,
navigators, smart icons). It is important to follow these
guidelines to develop Notes applications which are accessible.
Table of Contents:
Checklist for accessible Lotus Notes applications
References and resources
Follow this checklist to make your Lotus Notes 4.x applications
accessible.
Please fill out all checklist items. Enter Y if the checklist
item is supported in the offering, N if not supported, and N/A
if not applicable to the offering. For all checklist items that
are not supported or not applicable, enter a brief explanation
in the comments section.
IBM Lotus Notes 4.x Accessibility Checklist - Version 2.1
January 11, 2000
* 1.1 Navigator actions.
Provide alternate methods to accomplish actions available
through the graphical navigator. Make all navigator actions
available through the keyboard.
1.1 Rationale.
Navigators provide a graphical display of folders, views and
design elements to make it easier for most users to find
information. However, you cannot access the navigator without
the use of a mouse and the graphical display of information is
inaccessible to assistive technologies like screen readers. In
order to make navigators accessible to those who are using the
keyboard or a screen reader, it is important to provide an
alternative method to accomplish the same functions. This is
especially true for full screen navigators which do not enable
the user to use the View-Go To function to open the Notes
navigation pane to display the list of views.
1.1 Techniques.
* When a navigator is used to simplify the list of views
available to the user, the views listed in the navigator must
also be listed in the View menu. Open the View Properties. Under
the Options tab, select the option "Show in View menu". The name
of the view should be consistent with the name of the action on
the navigator.
* When a navigator includes actions, such as creating documents
or performing specific actions, there should be a corresponding
action in the Actions menu with equivalent function. If the
navigator has an option "Submit a badge request", there should
be an action "Submit a badge request" in the Actions menu with
the same function.
1.1 Testing.
* Open each action on the navigator and make a note of the
function for each action.
* Remove the mouse.
* Using only the keyboard, verify there are equivalent actions
available for all navigator actions.
* If the action opens a view, verify there is a view with the
same name listed in the View menu.
* If the action creates a document, verify there is an action in
the Actions menu with the same name or the document is listed in
the Create menu.
* If the action opens another database, verify there is an
action in the Actions menu with the same name as the Navigator
action.
1.2 Navigator backgrounds.
Do not embed the hotspot text or link text into navigator
bitmaps.
1.2 Rationale
Most navigators include graphic backgrounds as well as a
combination of graphic and text hotspots. When the text for the
hotspots is embedded in the graphic background, that information
is not available to screen readers. The screen reader cannot
access information about the links, even if the user tries to
use the mouse to explore the navigator. In order to make the
text on the background accessible, it cannot be included as part
of the bitmap for the background.
1.2 Techniques
When you add the text boxes after you have pasted the graphic
background, it makes the design more accessible and enables you
to reuse the graphic for more than one navigator. Follow the
steps below to create a navigator without embedded text.
* In your graphics program, copy the graphic background you want
to use for your navigator to the clipboard.
* Open the database where the background will be added and
choose View-Design.
* In the navigation pane, click on Design-Navigators.
* Select the navigator you are editing and choose Create-Graphic
Background.
* Create the text boxes for your hotspots and place them on top
of the graphic background.
1.2 Testing
* The only method to test Navigators is to run the database with
a screen reader. Start the screen reader and then start Notes.
* If the Navigator is not full screen:
* F6 to switch to the Navigator pane.
* Using the screen reader's "Say All" command, read the
navigator.
* Using the screen reader's cursor commands, move through the
navigator and hotspots to be sure they are read. If they are not
read or if the screen reader says "blank", the text has been
embedded in the graphic and is not accessible.
* If the Navigator is full screen:
* Using the screen reader's "Say All" command, read the
navigator.
* Using the screen reader's cursor commands, move through
the navigator and the hotspots to be sure they are read.
If they are not read or if the screen reader says "blank",
the text has been embedded in the graphic and is not
accessible.
2.1 Include action buttons in menu
Include all action buttons in the Actions menu.
2.1 Rationale
Each form and view has its own action bar to display the actions
available for use with that part of the application. The action
bar cannot be accessed through the keyboard. If the actions are
only available on the action bar, many users will not be able to
use the application.
2.1 Techniques
You can make the actions on the action bar accessible by
including them as choices on the Actions menu. When you create
the action, select the option "Include action in Action menu".
Choices are displayed in the Actions menu in alphabetical order.
If you have a large number of actions this may not be the most
effective way to select frequently used actions. Someone using
the keyboard and a screen reader to search the list, must go
down the list in sequential order. If the most common action is
the last one in the list, this can be tedious. You can force the
names to appear in a different order by numbering the frequently
used actions so they appear at the top of the list.
It is also helpful to define meaningful accelerator keys for
your actions. Notes will assign an accelerator key to any action
in the Actions menu, but it may not be meaningful or easy to
remember. You can force the use of a specific accelerator key by
typing an underscore before the letter you want to assign as the
accelerator. The underline is not displayed on the action bar.
For example, to make S the accelerator for the Submit request
action, type _Submit request
2.1 Testing
* Remove the mouse.
* Using only the keyboard, verify there are choices in the
Actions menu for all buttons on the action bar.
2.2 Provide text labels for buttons
Provide text labels for all buttons. Do not create buttons
without labels or buttons which only use graphical icons to
describe the function of the button.
2.2 Rationale
Screen readers rely on the text label on buttons to describe the
purpose of the button. If action buttons only use icons, the
buttons are not accessible to screen readers. Sighted users can
see the printer icon on an action button and know they can press
it to print their document. Since the screen reader does not
have information about the icon, it only reads "button". If that
same action button was included in the Actions menu, it will
have a blank title. When a button does not contain a text label,
there is no way to determine the purpose of the button. The same
is true for buttons within forms. If there is no text label, the
screen reader will say "button".
2.2 Techniques
* To create a text label for a hotspot button, select the
button and open the Button Properties box. On the Button
Info tab, go to the Button Label field and enter a name for
the button.
* To create a text label for an action button, select the
button and open the Action Properties box. On the Basics
tab, go to the Title field and enter a name for the button.
* To create an "invisible" text label for a hotspot button,
select the button. In the Button Properties box, go to the
Button Label field and enter a name for the button. Change
the color of the text label so it is the same color as the
button. Change the font of the text to minimize the size of
the button. This technique can be used when you want to keep
the size of the button small and a sighted user can easily
determine the button function. Assistive technology like a
screen reader will still be able to read the text label,
even though it is "invisible" to the sighted user.
2.2 Testing
* Verify each button on the action bar contains a text label.
It is not sufficient to have only an icon on the button.
* Verify each button on the form has a visible text label.
* If a button on the form does not have a visible text label,
use Object Inspector to determine if the button has an
invisible label.
* Start Object Inspector
* Place the mouse over the button with no text label. Verify
there is a text value in the Name field.
3.1 Descriptive text for links
Provide descriptive text for all links, not just "click here".
Ensure each link makes sense when read out of context.
3.1 Rationale
A blind user must read documents sequentially with a screen
reader or use special navigation keys to navigate to each link.
When links say "go" or "click here" they don't make sense when
read out of context. If there are multiple links in a document
with the same text, you cannot differentiate the links without
going back to reread the document.
3.1 Techniques
Link text should be descriptive (more than "click here" or "go")
without being so wordy that it interferes with efficient
reading. Instead of writing
To return to checkpoint click here.
Make "return to checkpoint" the link.
3.1 Testing
* Open the document which contains links in read only mode.
* Navigate through the links. As each link is highlighted,
verify the link text is understandable out of context.
3.2 Text pop-ups
Provide an alternative when using text pop-ups to display
information.
3.2 Rationale
Text pop-ups provide additional information about a field or
form. They cannot be accessed through the keyboard or a screen
reader, so some users cannot access information in the pop-up.
3.2 Techniques
Use one of the following techniques to provide an accessible
alternative to text pop-ups:
* If the field is editable, include the information in the
field help description.
* Include the information in the on-line help documentation.
Context sensitive help can be accessed through a Help action
on the form.
* Provide a button on the form which will display the
information when pressed. The button can have the label "?"
to minimize the amount of space on the form.
* Add static text on the form to explain the field. For
example, if you wanted to explain the input format for a
date field:
Date: (mm/yy/dd) _________________
3.2 Testing
* Open the document which contains the text pop-ups.
* From the Actions menu, choose View-Show-Field Help to
display the Notes field help at the bottom of the window.
* Access the first pop-up with the mouse. Verify the same
information is available either through field help
(displayed at the bottom of the window), a help button, or
static text on the form.
4.1 Using color to convey information
Do not use color as the only way to convey information or
indicate an action.
4.1 Rationale
If color is used as the only way to convey information, users
who cannot identify or distinguish colors will not be able to
make use of the information. For example, asking users to press
the red button is not useful if they can't distinguish the red
button from other buttons on the screen. The software needs to
provide another way of making the information available in
addition to or in place of using color. For example, Notes
displays unread documents in the color red. But the unread notes
are also identified by an '*' in the first column; so someone
who cannot distinguish colors can still identify unread
documents.
4.1 Techniques
* In addition to using color, provide a brief text
description.
* In addition to using color, include a text character to
denote the information.
* Use other attributes, such as bold or italics to distinguish
text.
4.1 Testing
* Identify where the application uses color to convey
information and verify the information is provided in
another way.
* Print the document on a black and white printer and verify
you can still understand the information that was conveyed
in color on the screen.
4.2 Display values as icons
Do not use the option "Display values as icons" as the only way
to convey important information in view columns.
4.2 Rationale
In a view, the "Display values as icons" option can be used to
display a graphic icon in one of the view columns. Notes
provides a set of predefined column icons which can be used to
graphically represent special values in view columns. These
graphics are not accessible and cannot be read by screen
readers. For example, in the Inbox, there is a graphic to
indicate if a memo contains an attachment. The attachment
graphic is not read by the screen reader, but Notes does provide
an alternate way of viewing attachments using the By Attachments
view.
If important information is only provided through the use of an
icon, some users will not be able to view that information. For
example, in a Resume database there is a view to display
candidate documents which uses the "checkmark" icon to show
those candidates which have received a job offer and the "X"
icon to show those employees who have not received a job offer.
If there was no other way to identify job offer status in the
view, someone using a screen reader would have to open each
document to see who had a job offer.
4.2 Techniques
When using the "Display values as icons" option, it is important
to provide an alternative way of getting the same information.
When the column icon is only used to make certain documents
stand out in the view or to enhance the look of the view, it is
not necessary to provide an alternative way of viewing the
information. If the information is important, then the developer
should use one of the following techniques:
* Include another view column with the text describing the
information represented with the icon.
* Provide an additional view with the information about the
icon provided in text format.
4.2 Testing
* Open the view(s) where icons are displayed in view columns.
* If the icon is used to provide important information, verify
the information is provided in an alternative method.
* Does the view contain a column which describes the
information represented by the icon?
* Is there another view which provides columns or categories
with the information represented by the icon?
5.1 Include forms in Create menu
Include forms in the Actions menu if they are needed by end
users to create new documents.
5.1 Rationale
Most applications allow users to create new documents using
action buttons or a navigator links. Since these objects are not
accessible, the form should be included in the Create menu or
the Action menu so it can be accessed from the keyboard or a
screen reader.
5.1 Techniques
* To add a form to the Create menu, select the form and open
the Form Properties box. Select the option "Include in
menu". Then select "Create Menu" as the menu where the form
will be included. The Create menu sorts form names in
alphabetical order. If you want the form to appear in a
different order, you can number the forms or rename them so
frequently used forms are at the top of the list.
* To add a form to the Action menu, identify the view where
users will want to create new documents using the form. Open
that View in design mode and choose Create-Action. In the
Actions Properties box, enter a name for the action in the
Title field. The name should be descriptive of the task like
"Create Badge Request". Select the option "Include in Action
menu". In the formula window, enter the formula to create
the new document.
* If the application has multiple forms beginning with the
same letter, Notes will assign a default keyboard shortcut
using the first letter not already used by another form. To
ensure the accelerator key to access the form is meaningful,
you may need to change the name of the form or force the use
of a specific key. You can force the use of a specific key
by typing an underscore before the letter you want to assign
as the accelerator. For example, to make V the accelerator
for the Interview form, enter "Inter_view" in the Name field
of the form.
5.1 Testing
* Identify documents that can be created by the end user in
the database.
* Verify the documents can be created using the keyboard.
* Open the Create menu. Verify the form name is displayed in
the list.
* If the form is not in the Create menu, open the Actions
menu. Verify there is an action displayed to create the
document.
5.2 Field help
Provide short field help for all user editable fields on the
form.
5.2 Rationale
Field help gives users additional information to assist them
with filling out documents. The field help can tell users what
to enter in the field or how to use the field. While this is
useful to everyone, it is particularly important to someone
using a screen reader. If field help is not available, a sighted
user can always read the field label to understand the field's
general purpose. However, the field label is not always
accessible to a screen reader, so someone who is blind may not
know the label or the label that is spoken may not be correct.
The user must rely on the field help to tell them about the edit
field and to confirm the field label. Most screen readers
provide a special hotkey which allows Notes users to read the
field help line.
5.2 Techniques
When designing a new field, The text of the help should follow
these general guidelines:
* Open the form and select the editable field where you are
entering the help. Open the Field Properties box and select
the Options tab. Write a brief description in the Help
Description field.
* Field help should be no longer than 4-6 words in length.
Field help should be descriptive without being too wordy.
When the field help is queried using a screen reader, the
entire help line must be read. If the help is too long, it
becomes non-productive and interrupts the reading of the
rest of the document. For example, field help to enter the
name of an interview candidate should say "Interview
candidate's name." instead of "Enter the name of the person
interviewing for this job".
* Start the description with "Required" if the user must fill
in the field to save the document.
* Use words like Select if the field is requires making a
choice instead of entering data. For example, "Select the
language to be spoken."
5.2 Testing
* From the Actions menu, choose View-Show-Field Help to
display the Notes field help at the bottom of the window.
* Open the document(s) with edit fields in edit mode.
* Tab to each edit field. As you tab to the field, verify the
field help is displayed at the bottom of the window.
* If a field is not editable (e.g., computed or read only), no
field help will be displayed.
5.3 Field labels
Associate labels clearly with controls and objects.
5.3 Rationale
A label provides the user with a general description about the
control, object or input area. In Notes, there is no way to
programmatically associate the field name for the control with
the static text label. Consequently, screen readers rely on
proximity of the label and the control to identify which labels
are associated with a control. If a label is too far away from
the control, it will not be spoken, or may be associated with
the wrong control.
5.3 Techniques
Place text labels immediately to the left or immediately above
the control.
* If tables are used to align information, do not make the
table columns which contain the labels too wide. If the
label is too far apart from the control , it will not be
identified correctly by assistive technology.
5.3 Testing
* Test the database using a screen reader. Load a screen
reader and then start Notes.
* Using the keyboard, tab to each control in the document.
Verify the screen reader speaks the appropriate label for
each entry field.
5.4 Background patterns
Provide the capability for users to turn off patterned
backgrounds behind text or graphics.
5.4 Rationale
Notes provides the capability to paste graphics files as a
background for a form. While this may add to the visual appeal
of the form for most users, the background may make it difficult
or impossible for some users with visual impairments to read the
data on the form. Many users need high contrast between the
background and foreground objects like text and graphics in
order to read the documents.
5.4 Techniques
In Notes 4.6 and later, you can allow users to override the form
background. Open the Form properties and click on the Background
tab. Select the option "Allow users to override background
properties."
5.4 Testing
The background graphic or color for a form must be modified on a
document basis. You cannot modify the background in one document
and have it take effect for all documents. Each document must be
modified individually.
* In Notes 4.6, open a document with a graphic background in
edit mode.
* Open the Document properties and select the Background tab.
* Modify the background by changing color or removing the
graphic background. If these options are grayed out, the
background cannot be changed.
5.5 Window titles
Provide a descriptive title for each form.
5.5 Rationale
The window title is the text that appears in the title bar when
a user composes, reads or edits a document. The window title
helps users understand the context of the document they are
reading. If no window title is defined, the word "Untitled"
appears in the title bar. The window title can provide important
information about the document to someone who is blind. When the
screen reader reads items in the Window list, the first item
spoken is the Window title. This helps a user who is blind
determine if they have opened the correct document without
having to actually read through the document.
5.5 Techniques
Use the following techniques to provide descriptive window
titles for each form.
* Open the form you are designing and select "Event: Window
Title" in the design pane. Enter a window title (enclosed in
quotes) in the formula window.
* Define a window title which changes based upon the status or
use of the document. For example, a different window title
should be defined for new documents. Once the document has
been created, the window title should include helpful
information such as the date it was created or the status of
the document
.
5.5 Testing
Testing should verify that there are no documents with a window
title of "Untitled" and that the window title is different for a
new document versus reading or editing an existing document.
* Open a document. Verify the document has a valid window
title (something other than "Untitled"). The window title is
displayed in the title bar at the top of the screen.
* Create a new document and save it. Verify the window title
indicates that this is a new document. For example, "New
Employee Document".
* Open the document you just created. Verify the window title
provides additional information about the document such as
"Employee Document for Jane Doe".
5.6 Logical tab order
Provide logical tabbing order between fields in forms and layout
regions.
5.6 Rationale
Users who are blind or have certain motor disabilities must use
the keyboard to navigate an application. When using the
keyboard, you have to navigate sequentially through the
application, you cannot "skip" items. Random tab order can make
the form unusable. The tab order should be consistent with the
way you fill out a form. Typically the user starts at the top
left and moves towards the bottom right. It would not make sense
to tab to the first object to fill in your first name, and then
tab to the object to fill in the state and then back to the
object to fill in your last name.
5.6 Techniques
In general, the tab order should start at the top left and move
towards the bottom right. Use the following techniques to set
the tab order:
* To set the tab order for fields in layout regions, open the
form with the layout region. Click the first field in the
layout region and choose "Design-Bring to Front". Select the
next item in the tab order and choose "Design-Bring to
Front". Continue with each field going in a logical order
from top to bottom.
* Tab order in forms is set implicitly when the form is
designed. Make sure that the layout of the form is logical
as you tab from object to object.
5.6 Testing
* Unplug the mouse and navigate forms and dialog boxes using
the keyboard.
* Verify the order in which objects are navigated makes sense
(usually top to bottom and left to right).
6.1 Alternate text for graphics
Provide text equivalents for important graphics.
6.1 Rationale
Adding text descriptions for graphics allows users who are blind
or those with text-only browsers to visualize the graphics.
Screen readers use the text description (alternate text) to
identify the images to the user. For users with graphical web
browsers, the text descriptions serve as placeholders for
graphics while the browser is loading the image.
The alternate text should be meaningful, like "home page" or
"search" or "products." When images are not links, use alternate
text carefully. A person having to listen to a document cannot
ignore text the way a person viewing the document can ignore a
picture. If images are not important or if they are redundant,
then do not include the alternate text, telling the screen
reader or browser to ignore the image.
6.1 Techniques
In Notes 4.6, you can provide alternate text for graphics.
Select the graphic and from the Actions menu select
Picture-Picture Properties. Under "Alternate text for Web and
deferred loading", type the text which summarizes the function
of the graphic. This feature is not available in earlier
versions of Notes.
6.1 Testing
Alternate text for graphics can be verified using Object
Inspector. As you mouse over the graphic, the Name or
Description field should display the description of the graphic.
* In Notes 4.6, open the document which contains the graphics
to be tested.
* Start Object Inspector.
* Move the mouse over the graphic. There should be a short
description of the graphic in the Name field in Object
Inspector.
Object Inspector
Object Inspector is an application provided by Microsoft as part
of the Software Development Kit (SDK) for Active Accessibility.
Inspector can be used to validate the aspects of accessibility
of software user interface elements which use Microsoftr Active
Accessibilityr or standard windows controls. It supports
software written for the Windows 9x, Windows NT or Windows 2000
platforms. Object Inspector can be downloaded as part of the
Microsoft SDK by going to
http://www.microsoft.com/enable/msaa/download.htm#SDK. There is
no charge to download and use the SDK.
Once the SDK has been installed, go to the Program Menu, select
Microsoft Active Accessibility SDK and then Inspect Objects.
When Object Inspector is loaded, it displays information about
the properties of an object as you select the object with the
keyboard or move the mouse over the object. If the software uses
Windows standard controls, or if the controls are non-standard
and MSAA has been implemented, Inspector will report the
information. If the software uses custom controls which are not
exposed through MSAA, the properties will be blank and that is a
failure for accessibility. The following properties may be
exposed by the application.
* Name - a string used to identify, find or announce an object
(e.g., text on a button or tab, prompt on an entry field).
* Role - describes what kind of user interface element an
object is (e.g., push button. radio button, check box, combo
box, edit box, page tab).
* State - describes an object's current status (e.g.,
selected, focused, selectable, unavailable, checked,
unchecked).
* Value - represents visual information contained by the
object. For example, the value for a link is the URL for the
link, an edit field may have default text, the current item
in a combobox.
* Description - provides a textual description of object.
* Help - provides information that tells the user about an
object's function. This is typically used for balloon style
information (e.g. ToolTips).
* KeyboardShortcut - describes a key or key combination that
will activate a specified object.
* DefaultAction - describes the object's primary method of
manipulation.
The graphic below shows a screen shot of Object Inspector when
the focus is on a button. For a selectable control, the
important properties are Name, Role and State. The value of the
Name property is "Yes" because that is the button label. The
Role property identifies the type of control, which in this case
is a push button. The value of the State property is "Normal"
because the button is not selected.
Using Object Inspector to verify selectable controls (e.g.,
radio buttons, check boxes, push buttons)
Selectable controls are accessible if they provide accurate
information about the following properties in Object Inspector.
If any of the following fields are blank, the software is not
accessible.
* Name: The name associated with the control. For example, in
Notes Mail, there is a checkbox to identify confidential
memos. The value of the Name property should be IBM
Confidential.
* Role: The type of control (radio button, check box, push
button).
* State: The state should be one or more of the following as
appropriate - checked, unchecked, default (to indicate
default push button), normal, focused, focusable,
unavailable.
Using Object Inspector to verify graphics
Graphics are accessible if they provide accurate information
about the following properties in Object Inspector. If any of
the following fields are blank for important graphics, the
software is not accessible.
* Name: Text which describes the graphic.
* Role: The type of control (graphic, link).
* State: The state should be one of the following as
appropriate - focusable, selectable, focused.
* Value: The value of the URL for graphic links.
Using Object Inspector to verify edit controls
Graphics are accessible if they provide accurate information
about the following properties in Object Inspector. If any of
the following fields are blank, the software is not accessible.
* Name: The text in the edit field. If there is nothing in the
field, the Name property will be blank.
* Role: The type of control (edit box, drop down list, combo
box).
* State: The state should be one of the following as
appropriate - focusable, selectable, focused.
* Description: The field label or help information about the
control.
Screen Readers
Someone who is blind requires a screen reader to use a computer.
A screen reader makes information on the screen available as
synthesized speech or a refreshable braille display. Screen
readers can translate text information or graphics which have
alternate text describing the images. The ability of the screen
reader to read the software depends on the software's use of
standard operating system controls or accessibility APIs such as
Microsoft Active Accessibility (MSAA) for the Windows
environment.
Henter-Joyce, Inc. offers a free demonstration copy or a timed
evaluation copy of JAWS for Windowsr on their web site at
http://www.hj.com/. The free demo is fully functional for 40
minutes each time you start a new Windows session, and includes
the Eloquence for JFW speech synthesizer. The timed evaluation
copy is available for a nominal fee and runs for 60 days.
GW Micro offers a free demonstration copy of Window-Eyesr on
their web site at http://www.gwmicro.com/. The free demo is
fully functional for 30 minutes each time you start a new
Windows session. You have to restart Windows to continue to use
Window-Eyes for another 30 minutes.
References and resources
* Overview of the new Lotus Notes R5 accessibility features.
* The Best Practices Guide for Lotus Notes 4.x
----------
>From the web page
http://www.austin.ibm.com/sns/accesshardware.html
Hardware accessibility
Hardware accessibility guidelines increase the accessibility to
hardware for people who have disabilities. Hardware includes
physical items like latches, keys, and physical input and output
connections.
Table of Contents:
Checklist for accessible hardware
References and resources
Follow this checklist to make your hardware accessible.
Please fill out all checklist items. Enter Y if the checklist
item is supported in the offering, N if not supported, and N/A
if not applicable to the offering. For all checklist items that
are not supported or not applicable, enter a brief explanation
in the comments section.
IBM Hardware Accessibility Checklist - Version 2.1
January 11, 2000
1.1 Accessible controls and latches
Controls and latches which are required on a regular basis for
system operation should be accessible and operable with one hand
and minimal dexterity.
1.1 Rationale
Users with little or no use of their hands or with limited reach
can have difficulty accessing and manipulating some controls.
System controls which are located at the rear of the system
cannot be operated by a user in a wheel chair or with limited
reach. A user with limited dexterity cannot use latches or
controls which require a twisting motion to activate them. A
user with one hand cannot open some laptop computers.
1.1 Techniques
Controls and latches used on a regular basis should be located
near the front of the system and need to have controls which are
easy to activate. "Regular basis" can be defined as those
controls which are required on a daily basis. The control to
turn on the system would be used on a regular basis. The control
to replace a hardfile would not be used on a regular basis. The
following techniques should be used for system controls used on
a daily basis.
* Locate controls on the front of the system for each reach.
* Use controls and latches which are easily differentiated
tactilely from the main surface of the product.
* The force required to activate the control should be no more
than 10 to 20 ounces for finger activation and 10 to 80 ounces
for palm activation.
* Use controls and latches which require light pressure such as:
* Up/down control buttons
* Concave rocker switches
* Sliding controls
* Concave buttons
* Avoid controls which require a twisting motion or a push and
twist motion.
* Avoid push-pull controls.
* Avoid controls which are required to be held down for a period
of time.
1.2 Concave buttons
Use concave buttons to assist mouth stick or head stick users.
1.2 Rationale
Concave buttons provide the easiest mechanism for a user using a
mouth stick or head stick to activate controls. These controls
are easy to differentiate and easier to activate.
1.2 Techniques
When possible, use concave buttons to activate controls.
2.1 Tactile landmarks on keys
Provide tactile landmarks on home row keys (e.g., F and J on
QWERTY keyboard, 5 key on the numeric keypad).
2.1 Rationale
Tactile landmarks provide a frame of reference, so users can
find and maintain their "home" location on the keyboard or
keypad.
2.1 Techniques
Provide tactile labels (nibs) on home row keys. Tactile labels
should be raised 1/32". It is better to provide the tactile
landmark on the key rather than above or below the key.
The home key(s) can be distinguished with different depth of
concavity.
2.2 Toggle key indicators
Provide a visual (or tactile) and auditory indicator of each
toggle key (e.g. Caps Lock) or make the state of that toggle key
available to software so that it can provide alternative
indicators.
2.2 Rationale
Toggle keys, like the Num Lock, Caps Lock and Scroll Lock keys
on the keyboard typically provide only visual feedback. A user
who is blind or visually impaired cannot determine the state of
those keys. The status should be provided in a redundant way so
a user who is deaf can see the state or a user who is blind can
hear or feel the state. If the state is available to software,
assistive technology can access the state and announce when the
toggle key is on or off.
2.2 Techniques
Toggle keys should use one or more of the following techniques
to make them accessible.
* Provide auditory feedback in addition to visual feedback of
the state of the key
* Provide tactile feedback on the state of the key
* Make the state available to software. This information can
then be used by assistive technology and some operating systems
to provide an audio indication of the state when it changes.
The UseToggleKeys setting in the Accessibility Options dialog of
Windows illustrates one method of providing an audio indication
of changing the state of
toggle keys.
2.3 Industry standard layout
Provide an industry standard keyboard and keypad layout.
2.3 Rationale
An industry standard layout for keyboards and keypads makes it
easy for a user with a visual impairment to move to a new device
and be able to find the keys they need. For example, it would
not be a problem to change computers since most systems use the
standard QWERTY keyboard or the standard layout on numeric
keypads.
2.3 Techniques
Industry standard layouts include:
* QWERTY layout for keyboards
* 12 key Telephone Keypad
* 17 key Numeric Keypad
2.4 Tactilely discernible keys
Provide keys which are tactilely discernible without activating
them (e.g., for flat membrane keyboards provide overlays).
2.4 Rationale
A user who is blind or visually impaired may have difficulty
distinguishing flat membrane keys or buttons unless there is a
tactile distinction between the keys. Users need to be able to
identify the keys without activating them.
2.4 Techniques
Keys can be located tactilely using one of the following
techniques.
* Provide ridges around the keys.
* Provide a bump or depression on the key.
* Provide a keyguard or overlay option.
3.1 Accessible media
Allow frequently accessed media to be inserted and removed using
minimal reach and manual dexterity.
3.1 Rationale
A user with poor motor control or limited strength and dexterity
can have difficulty handling media or inserting the media into
drives. Frequently accessed media (e.g., diskettes or CD ROMs)
need to be easy to reach, insert, and remove.
3.1 Techniques
* Locate drives on the front of the system for easy reach.
* Removable media should eject and/or protrude far enough to
provide clearance beyond the frame and cover overlap.
* Pushbutton ejection systems which require low pressure allow
for easy access to the media.
* Allow receptacles to be repositioned or re-angled to be more
reachable.
* Whenever possible, allow the object to be inserted in
several ways (e.g. a six-sided wrench can be positioned on a
matching bolt six different ways; two sided keys can be
inserted upside down).
* Provide visual contrast between insertion point and the rest
of the device (making a more obvious "target").
* Clearly mark the proper orientation both visually and
tactilely.
3.2 Loading and unloading media
Provide the capability to load and unload the media by
pushbutton, by pressing a keyboard key, or by software eject.
3.2 Rationale
Controls that are operable from the keyboard facilitate access
to these controls by individuals who are using alternate input
devices.
3.2 Techniques
* Have the drive detect the presence of the media and
automatically pull the media into the drive.
* Beveled slots or edges facilitate insertion of cards,
diskettes or CD's. Tactile and visual cues should also be
provided to indicate the proper orientation of the object to
be inserted.
* The pushbutton should not be located below the media drive.
4.1 Industry standard ports
Provide industry standard ports for alternative input devices or
switches.
4.1 Rationale
A user with mobility impairments cannot use the standard
keyboard or mouse. The system needs to provide an industry
standard port (e.g., serial, parallel), so the user can attach a
switch or other alternate device to replace the keyboard. The
system would regard this device as its keyboard, and the user
would be able to input any valid keystroke combination available
from the regular keyboard.
4.1 Techniques
Provide an industry standard serial or parallel port which can
be used to attach alternate input devices.
5.1 Attaching large displays
Provide an option to attach larger displays through a standard
display connector.
5.1 Rationale
A user who is visually impaired can have difficulty seeing
normal text and graphics on the screen because the characters
are too small. By attaching a larger display, the size of the
screen is increased and allows for increased magnification of
the characters. The large display can work in conjunction with
software support for magnification.
5.1 Techniques
Provide a standard display connector to enable users to attach
larger displays which meet their needs. A standard video
connector or I/O slot that allows connection of a video control
card would satisfy this requirement.
5.2 Displays with non-glare and repositionable screens
Provide a non-glare screen and allow displays to be
repositioned.
5.2 Rationale
A user who is visually impaired can have difficulty seeing
normal text and graphics on the screen due to screen glare. By
repositioning the screen, the characters can have greater
contrast and be easier to see and read. The ability to
reposition the screen is also important for users in
wheelchairs, or with other physical limitations, who would need
to adjust the screen to their needs.
5.2 Techniques
Displays should be able to be repositioned so they can be viewed
by all potential users. Use non-reflective display surfaces to
minimize glare.
6.1 Color
Do not use color as the only way to distinguish keys or
controls.
6.1 Rationale
If the hardware conveys information by color alone, users who
cannot identify or distinguish colors will not be able to make
use of the information.
6.1 Techniques
Make color codes redundant with other codes by supplementing
color coding with text, shape or relative position coding. To
ensure that a color blind user will not miss any important
information, use colors that vary in intensity (have sufficient
brightness contrast).
6.2 Large lettering and high contrast colors
Use large, easily readable lettering and high contrast colors.
6.2 Rationale
A well-designed label enables the user to quickly scan a product
and find the item of interest. If the labels have small
lettering and are written in low contrast colors, a user with a
vision impairment may not be able to identify them.
6.2 Techniques
* Where appropriate, provide large, easily readable lettering
to facilitate the initial learning of equipment and the
efficiency of operating occasionally used equipment.
* Provide high contrast color labels. Light gray on slightly
darker gray is stylish but does not provide sufficient
contrast.
* Where appropriate, provide tactile labels that have raised
text or icons. Tactile labels should be raised 1/32".
7.1 System sounds
Provide an interface so that use of system sounds can be known
to software.
7.1 Rationale
Many systems use the speaker to announce warnings or errors to
the user. A user who is deaf or hard of hearing will not be able
to hear and respond to the warning. Systems need to provide an
interface so that software can provide an alternative method of
providing the information.
7.1 Techniques
Systems need to provide redundancy of important system sounds by
doing one of the following:
* Provide an interface to system sounds for application use.
* Provide a visual equivalent of the system sound (e.g.,
flashing the screen, displaying the warning on the screen).
7.2 Volume control
Provide a physical volume control or provide an interface so
that volume can be controlled with software.
7.2 Rationale
A user with a hearing impairment can have difficulty hearing
auditory output and needs to adjust the volume so they can hear
the warnings and messages.
A user with a vision impairment may depend on speech output that
uses the system sounds.
7.2 Techniques
Volume control can be supported by:
* Providing a physical volume control on the system,
preferably the front. Provide visual and non-visual
indication when the volume is in the off position.
* Providing a software interface so the user can adjust volume
through the software.
* Providing an audio output jack on the system where
appropriate; this is important for applications which use
speech output as the standard interface. The user will need
to adjust the volume so they can hear without disturbing
others.
8.1 Accessible documentation
Upon request, provide documentation in an accessible format such
as ASCII text or HTML.
8.1 Rationale
Some users may not be able to access product documentation if it
is not in an accessible format.
8.1 Techniques
* Upon request, provide product documentation in ASCII text or
HTML format.
* Include text descriptions of illustrations (graphics) in the
documentation.
* Considerations in the Design of Computers to Increase Their
Accessibility by Persons with Disabilities Version 4.2 May,
1988, Trace Research and Development Center.
* The PC97 Logo Handbook contains Microsoft's recommendations
for how to make computer hardware accessible.
* Final report to the Access Board of the Electronic and
Information Technology Access Advisory Committee.
* Guidelines for the design of consumer products, and
additional guidelines are available from the Trace Research
and Development Center.
* Resource Guide for Accessible Design of Consumer Electronics
at http://www.eia.org/eif/toc.htm
* Access to Telecommunications Equipment and Customer Premises
Equipment by Individuals with Disabilities. TAAC Final
Report.
----------
End of Document