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
![3D"Solutions"](3D"http://www.ibm.com/solutions.gif")
![3D""](3D"http://www.ibm.com/filler.gif")
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.
![3D"areas](3D"welcome.gif")
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.
![3D"Of](3D"piechart.gif")
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
<___>
![3D"skip](3D"blank.gif")
...