Guidelines for Accessible and Usable Web Sites: Observing
Users Who Work With Screen Readers1
Mary Frances Theofanos
National Cancer Institute
Rockville, Maryland, USA
now at
National Institute of Standards and Technology
Gaithersburg, Maryland, USA
mary.theofanos@nist.gov
Janice (Ginny) Redish
Redish & Associates, Inc.
Bethesda, Maryland, USA
ginny@redish.net
The Communication Technologies Branch of the United States National Cancer
Institute (part of National Institutes of Health and Department of Health
and Human Services) has been conducting usability testing with people
with disabilities, specifically blind and lowvision users, to
- understand the relationship between accessibility and usability
- understand how blind and low-vision users work with Web sites
- develop research-based guidelines for accessibility and usability
- assess the usability of specific Web sites for blind and low-vision
users
Since June 2001, U. S. federal Web sites must comply with Section 508
of the Rehabilitation Act (29 U.S.C. §794.d). This law requires that
agencies provide access to electronic information to people with disabilities.
Section 508 identifies 16 specific standards for Web site accessibility.
2
Meeting the required accessibility standards does not, however, necessarily
mean that a Web site is usable for people with disabilities. And if a
Web site is not usable, it is not really accessible, even if it has all
the elements required by the law.
Why Accessibility?
Why should you design Web sites that are both technically accessible
and also usable for people with disabilities? Here are six compelling
reasons:
- Disabilities affect many more people than you may think.
Worldwide, 750 million people have a disability and three out of every
10 families are touched by a disability [10]. In the United States,
one in five people have some kind of disability and one in 10 has a
severe disability. That’s approximately 54 million Americans [8].
In 2001, 180 million people worldwide were blind or visually impaired,
including 7.7 million people in the United States. This is a substantial
consumer segment that should not be ignored.
- It's good business. According to the President’s
Committee on Employment of People with Disabilities [6], the discretionary
income of people with disabilities is $175 billion!
- The number of people with disabilities – and income
to spend – is likely to increase. The likelihood of having
a disability increases with age, and the overall population is aging.
- The Web plays an important role and has significant benefits
for people with disabilities. Of the 54 million Americans with
a disability, 4 in 10 are online [2]. These users spend more time logged
on and surfing the Internet than nondisabled users. On average, they
spend 20 hours per week online. In addition, they report more positive
feelings about their interactions. Our participants told us over and
over how the Internet has opened up a whole new world for them and has
given them a sense of independence and freedom. For example, P7 is able
to read the newspaper herself for the first time. P5, who was unemployed
at the time, spends more than 12 hours a day online, listening to the
radio, "reading" Web sites, and chatting. According to the
Harris Poll, 48 percent of respondents with disabilities reported that
the quality of their lives had been significantly improved by the Internet
compared to 27 percent of respondents without a disability [2].
- Improving accessibility improves usability for all users.
As you'll see in the findings and guidelines in this paper,
making Web sites work for people who use screen readers takes little
extra effort while bringing great benefits for everyone.
- It's morally the right thing to do.
The Project
Between November 2002 and February 2003, we observed and listened to
16 blind users as they worked with Web sites using assistive devices that
read the screen to them (screen readers). Participants used the screen
reader that they work with regularly: 13 used JAWS [3] and three used
Window-Eyes [9]. 3
A spokesperson for the U.S. National Federation of the Blind estimates
that, in the United States overall, JAWS commands 65 percent of the market
in screen readers; Window-Eyes has 35 percent of the market. The 80 percent
proportion of JAWS users in our sample reflects the situation in the Washington,
D.C., area where JAWS is the software most commonly used by U.S. federal
workers.
For information about available screen reading software, see http://www.tiresias.org/equipment/eb9.htm
[11].
Our 16 participants ranged from unemployed to consultants on Web accessibility.
What the Participants
Each participant worked individually with us for two hours (except P7
who was only able to spend one hour because she had transportation difficulties).
At the beginning of each session, we invited the participant to customize
the screen reader software. Most checked the voice and speed but did not
customize it further. We have found that users who work with screen magnifiers
customize them extensively, but that users who listen to screen readers
do not.
Most users of screen readers listen at an incredibly fast rate. Some
of our participants indicated that they were slowing the speech for us
– that they typically listened at an even faster rate than the one
they used in the usability test session.
We began each session with a few questions about expectations and about
how the participant typically works with Web sites. At the end of each
session, we asked questions about reactions to the experience and to the
specific sites the participant visited.
For most of the session, participants used the Internet to complete scenarios
that we suggested (in typical usability testing fashion):
- November: eight scenarios starting at www.hhs.gov,
including one of their own
- December: 11 scenarios (the ones from November plus three to test
applications)
- January: seven scenarios (three related to forms and four related
to anchor links)
- February: nine scenarios (on search engines, anchor links, and FAQs)
All of the sites in the study were U.S. government sites in the .gov
domain. However, in the study of search engines, participants went to
both www.firstgov.gov and www.google.com.
What We Learned
Our focus has been understanding how blind users work with Web sites
and what that means for designers and developers. Our focus therefore
is users rather than specific Web sites. In the following sections we
describe insights gained from our observations and we present guidelines
that can help designers and developers both meet the letter of the law
and actually make Web sites usable to people who listen to screen readers.
Following the guidelines that come from this study should take no more
time or effort than developers are now spending to get a good score from
an automatic program like Bobby [1] or LIFT [4] while doing a better job
of meeting people's needs.
The following 16 sections are grouped into lessons learned about
- using a screen reader
- navigating through Web sites
- filling out forms
At the end of each section, we give guidelines, numbered Guideline 1,
Guideline 2, and so on.
Using a Screen Reader
Screen-reader users scan with their ears.
Most blind users are just as impatient as most sighted users. They want
to get the information they need as quickly as possible. They do not
listen to every word on the page – just as sighted users do not
read every word. They "scan with their ears," listening to
just enough to decide whether to listen further. Many set the voice
to speak at an amazingly rapid rate.
They listen to the first few words of a link or line of text. If it
does not seem relevant, they move quickly to the next link, next line,
next heading, next paragraph. Where a sighted user might find a keyword
by scanning over the entire page, a blind user may not hear that keyword
if it is not at the beginning of a link or a line of text.
Blind users also object to listening to descriptions of elements, such
as decorative bullets that add no meaning to the page and that make
them wait through three words to get to the real meaning.
The frequent repetition of "updated"
at the front of links in this list makes the list very difficult
for screenreader users to scan. |
Users complained bitterly about listening
to the repetitive and meaningless words "decorative bullet
image." They said it kept them from getting the really
meaningful words, "home," etc. |
(Note: These two figures are not printed in
the Interactions article.)
Guideline 1. Write for the web. Write in short, clear,
straightforward sentences. Use bulleted lists. Put the main point at
the beginning of a paragraph. Write links that start with keywords.
See http://www.usability.gov/design/writing4web.html
for more on clear writing for the web.
Guideline 2. Use empty ALT text, ALT="" or
use a space as ALT-text, ALT=" " for decorative elements on
a page so that users do not have to listen to "decorative bullet
image" or "decorative line." Using empty ALT text for decorative
elements complies with 508 guidelines. When links are bulleted, there
is no need to identify the bullet, just the link name.
Screen-reader users must understand the browser, the screen
reader, and the Web sites – quite a mental load.
This is a realization that we came to part way through the project after
watching our participants struggle with their screen-reader software
as well as with the browser and the Web sites. Vision-impaired users
must get a good mental model of their assistive software as well as
of the site(s) they are going to.
It's like always being in a "help" system – having to
split your cognitive energy between the task you are doing and how to
use the system that is helping you. We all do this somewhat on the Web
in that we have to remember browser commands as well as a site's structure;
but if we think that way, vision-impaired users are splitting their
cognitive energy three ways – browser, screen reader, and site.
Most screen-reader users do not use the mouse. That means they depend
completely on keyboard commands, and some of the keyboard commands are
non-mnemonic key combinations. One of our participants, for example,
had recently switched from Outspoken, a Mac-based screen reader, to
Window-Eyes for the PC. He brought along his own "cheat sheets"
in Braille. You can imagine that having to work with them distracted
him from his work on the Web site and often made him lose his place
and train of thought.
Guideline 3. For developers of screen-reading software:
Make the commands mnemonic and intuitive.
Guideline 4. For designers and developers of Web sites:
Make the site structure clear and obvious. The more obvious the structure
of the site, the easier it will be for screen-reader users (as well as
for sighted users) to understand and use the site. For example, most participants
in this study found it easy to quickly understand and use the new home
page of the Department of Health and Human Services, shown in Figure 1.
The home page has 12 buckets with bullets as well as a right-side column
of news and special features. The search box is near the top. When users
first open this page, the screen reader tells them that the page has 43
links. Several participants commented that that was a reasonable number
for a home page. On other pages that had several hundred links, several
participants reacted strongly with words like, "Oh my!" and
"Wow!" indicating dismay had having to deal with so much.
Figure 1. Department of Health and Human Services home
page. Participants were able to get a "mental model" of this
page, which has a clear and simple structure.
-
Many users do not know or use all the features of the software.
Given the mental load of browser, Web site, and assistive device,
it should not be surprising that many of our participants did not
know all the features of the screen reader software. How many of us
take advantage of all the functionality of any of the products that
we use? How many of us update our software and yet do not learn to
use all the new features that come with the update?
Most of our JAWS participants regularly used the Links List (Insert-F7).
A few regularly checked the Window Title to see what page they were
on (Insert-T). Only a few used the Headings List (Insert-F6) or moved
from heading to heading by pressing H inside a document. No one used
the JAWS command, N, to skip links. No one jumped directly to a form
on a page. Only one of our participants, a JAWS trainer, used the
Virtual Viewer (Insert-F1), a JAWS feature that displays a description
of a Web page, so that the user can immediately find out how many
headers, tables, links, and other screen elements are on a page.
JAWS allows users to get a sense of the Web
page with this Virtual Viewer, but only one participant used
this feature. |
(Note: This figure is not printed in the Interactions
article.)
Guideline 5. For developers of the screen-reading software:
Consider providing training to help users get the most value from the
screen-reading software that they use. Consider building easy-to-use demos
and tutorials on new features.
The software does an amazing job but still mispronounces words.
Both JAWS and Window-Eyes read amazingly well, but unusual words, acronyms,
and abbreviations confuse them. JAWS mispronounced "content"
in the link "Skip to Content." (See the later section on "Many
want to skip the navigation.") See Chart 1 for a list of some other
words that came up in our study that caused problems for screen readers
– and, therefore, for our participants.
Chart 1
Word on the screen |
What JAWS says |
homepage |
hommapodge |
LiveHelp |
livahelp |
MEDLINEPlus (a very large
database of medical information) |
Medlynepalus |
FY (meaning "fiscal year") |
fie |
VA (meaning "Virginia") |
va (like the Spanish for "go") |
|
Guideline 6. Write "home page" as two words.
Guideline 7. Do not make up unusual names for products,
services, or elements of a Web site. Do not combine two or more words
into one name. (Of course, these names often predate the Web site, and
designers and developers cannot change them. Just do not add to the problem
– and alert others to the problem as well.)
Guideline 8. To make screen readers read an acronym
or abbreviation as letters rather than attempting to read it as a word,
use the <ACRONYM> and <ABBR> tags as explained at http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr.
-
Many screen-reader users do not want a special version ("text
version").
Some of the sites that our participants visited offer a "text
version" or a "screen reader version." Only two of
the 16 participants said that they liked using text versions. Others
argued strongly that two versions are not necessary; one version made
accessible is better.
(Note: These quotes are not printed in the Interactions
article.)
Guideline 9. For most Web sites, spend the available
time and effort making one version that is accessible to all rather than
creating and having to later maintain two separate versions.
Navigating through Web Sites
How do users working with screen readers find what they need on a Web
site? How do they deal with the repetitive global navigation that appears
on every Web page?
-
Many want to skip the navigation but do not do so.
Many Web sites include a Skip Navigation link at the beginning of
each Web page. Clicking on that link bypasses the global navigation
at the top (and left – depending on where the developer has
ended the skip navigation).
Our participants desperately wanted to not listen to the navigation
each time they got to a page. They wanted to get right to the content.
But only half of our participants knew what "skip navigation"
means. Some ranted to us about the problem of having to listen to the
same "stuff" on each page, but they did not choose "skip
navigation." Some jumped to the bottom of each page and scanned
back up the pages to avoid the "stuff" at the top.
If we think about that, it's not surprising. "Navigation"
in this context is Web jargon. In fact, the half that knew "skip
navigation" were the 508 consultants, the software engineer, and
the highly sophisticated computer users.
Some developers have used the phrase "skip to content" instead
of "skip navigation." That seems like a good idea. Unfortunately,
it does not work in JAWS because "content" can be a noun or
an adjective in English – and JAWS reads "skip to content"
with the accent on the second syllable, like the word for "happy."
Our participants did not understand that statement at all.
And no one used the JAWS keyboard command, N, which the screen reader
developers put into the product to meet 508 requirements and do what
Skip Navigation does even if the Web site developer did not include
a Skip Navigation tag.
Guideline 10. Include a "skip" link at the
top of every Web page. Name it "Skip to main content." JAWS
reads that correctly as the noun "content" with the accent on
the first syllable. That wording was much more meaningful to participants
than "skip navigation."
-
Many users jump from link to link or use a Links List box.
We all know that Web sites are made up of navigation pages and destination
pages. Some pages are primarily used to move toward a goal; others
are content pages that contain the end-state information users are
looking for. On pages that are primarily used for navigation, sighted
users often scan the page, focusing on the underlined blue (or whatever
seems like links).
Blind users are no different. They want to move forward quickly.
Screen readers assist them by allowing users to choose to listen only
to links. In both JAWS and Window-Eyes, users can do this by either
tabbing from link to link or by calling up a Links List (see Figure
2) – a separate window that lists all the links on the page.
(The keyboard command is Insert-F7 in JAWS and Insert-Tab in Window-Eyes.)
Figure 2. Example of a Web page with Links List.
A Links List brings all the links on the page into a separate box.
The user can then navigate in this box with the arrow keys or the
first letter of a link.
Within the Links List window, users can move quickly through the list
with the up and down arrow keys or they can jump by typing the first
letter of a link name. Our participants used this feature regularly.
More participants knew this feature than any other feature of their
screen-reader software.
They still scanned with their ears – even through the Links List.
They did not listen to all the links or to all of a link if the link
was more than a few words long. If many links start with the same words,
they get frustrated. If a link they are looking for is there but not
with the keyword they are thinking of at the beginning, they may not
find it – and again get frustrated.
Watching blind users work in a Links List makes it obvious why "click
here," "more," and other meaningless links just do not
work. The Links List removes all the context from the links.
A screen reader set to Links List would
say only "Answer," "Answer," "Answer"
for this page. (Also see the example earlier in the paper
in the section on "Screen-reader users scan with their
ears.") |
(Note: This figure is not printed in the Interactions
article.)
Guideline 11. Make links descriptive. Be sure that the
link will be useful by itself, with no surrounding text. Do not use "click
here," "more," "answer," or other repetitive
words or phrases as links. Look at www.aarp.org
for a site that consistently expands what used to be "more"
into meaningful links, such as "more travel articles," "more
of today's news," and so on.
Guideline 12. Start links with relevant keywords.
Guideline 13. Try not to have many links that start
with the same word or phrase. In some ways, these guidelines are obvious
and easy to implement. We know that even for sighted users, links should
be descriptions of what they go to rather than "click here"
or the URL. See http://www.usability.gov/pdfs/guidelines.html.
In many situations, if you write well for those who listen to Web sites,
you will also be writing well for those who look at the sites. For example,
even sighted users have difficulty when all the headings start with "how
to" instead of action verbs.
However, in some situations in which we write links, the needs of screen-reader
users may seem to conflict with what works best for sighted users. For
example, questions make excellent headings and links (see Figure 3),
but questions usually do not start with the keyword of the subject matter.
Figure 3. A list of questions like this works very
well for most sighted users, but our screen reader users were impatient
with the question word at the beginning and could not find out how to
volunteer. They wanted to use "v" to jump to a link about
volunteering.
A possible solution to meet the needs of all is to start links like
this with a keyword followed by a question, such as:
- Literacy – What is it?
- Volunteering – Where can I volunteer to work with adult learners?
Guideline 14. Start question headings with a keyword
followed by the question.
-
The Find feature does not cycle through the page –
and the screen reader moves the cursor as it talks.
Looking at the example of question headings where users wanted information
about volunteering to help in a literacy program, you might suggest
that users try the Find feature. Find tells users whether the word
they are looking for is on the page. Almost half of our participants,
seven of 16, tried Find. Some tried it repeatedly but were often unsuccessful.
One problem is that both the Window-Eyes Find box (CTRL-Shift-F)
and the JAWS Find box (CTRL-F) only search either down the page or
up the page from wherever the cursor is on the page. It does not cycle
through the page. Internet Explorer's Find box works the same way;
however, sighted users usually do not have a problem because they
leave the cursor at the top of the page while scanning for keywords.
Find in Window-Eyes defaults to only
looking from the cursor to the end of the page. The comparable
box in JAWS works the same way. |
(Note: This figure is not printed in the Interactions
article.)
Our screen-reader users had a problem because they were often in
the middle of a page when they decided to try Find. If the word they
were looking for was higher on the page than where JAWS or Window-Eyes
had stopped reading, Find would say that the word was not on the page
even when it was. Most participants did not realize that the Find
feature had not searched the entire page.
Another problem is that Find cannot read what is in an image (see
Figure 4).
Figure 4. Find will not pick up these words because
they are part of an image. (This page does have redundant text links
elsewhere on the page that helped users find the budget they were
looking for.)
Guideline 15. Pay attention to the wording on pages
and be sure that keywords that users would look up are actually on the
page. (This is useful for sighted users, too.)
Guideline 16. Make sure that the keywords are not in
images.
Guideline 17. For makers of screen-reading software:
Make Find cycle through the entire page.
When the ALT-tag and the text on a page differ, users may
type the wrong information in the Find dialogue box
When listening to a page, P16 heard an option to get a "printer-friendly
version." That's how Window-Eyes read the option. However, the
text on the page was "Print Answer." When this participant
wanted to find the option again, she tried to get it by going to the
Find box and asking for Printer. Find reported "Search string not
found" – presumably because "Printer" is not on
the page, even though it was what the software read to her from the
ALT-tag. (See Figure 5.)
Figure 5. Example of conflict between text in
ALT tag and text in image. The user found this by listening to the page.
The screen reader read "printerfriendly version" for this.
The user wanted to find it again, and so typed "printer" in
the Find dialogue box. The response was not matches. The user was confused
because she was sure she had used the printer-friendly option just a
few minutes ago on the same page.
Guideline 18. Do not create subtle differences between
the text on the page and the ALT text that can trip users up when they
search for words on the page.
Some users are poor spellers, which makes searching difficult.
These words read just like the correctly
spelled words "Virginia" and "terrorism,"
but they do not work to return correct search results. |
(Note: These figures are not printed in the
Interactions article.)
If users cannot find what they want by browsing links or using CTRL-F,
you would imagine that they would try searching. However, some vision-impaired
users spell poorly, which makes successful searching difficult. P7,
for example, said that she does not search because her spelling is poor.
She commended the U.S. National Institutes of Health site search at
www.nih.gov because it has spelling
help. Several participants mentioned the spelling help on Google.
Guideline 19. Use a search engine that provides help
with spelling, such as the one at www.google.com.
Anchor links can work well, but not if the page refreshes. In portals
and information-rich Web sites, second-level navigation pages and content
pages often include several topics on the same page. "Anchor links"
are links at the top of a Web page that users can click to jump quickly
to information further down the same page.
Our research with both sighted users and blind users shows that anchor
links can be very helpful. For example, both sighted users and blind
users found information quickly and easily in the Web site, Chemotherapy
and You, which has anchor links and did not find information
nearly as quickly or as easily in the Web site, Facing Forward,
which does not have anchor links.
These anchor links helped both sighted
and blind users. |
The lack of anchor links here hindered
both sighed users and blind users.
As a result of usability testing, this
site was changed to have anchor links. |
(Note: These figures are not printed in the
Interactions article.)
Watching both sighted and blind users working with Chemotherapy
and You was a pleasure. We had a different experience with the
second-level pages of www.hhs.gov.
We knew the pages worked well for sighted users, but we watched with
great frustration as our screen-reader users tried to use the anchor
links. When participants clicked on an anchor link, the page would
briefly jump to the correct place, but then it would revert to the
top of the page and JAWS or WindowEyes would start to read the page
again from the top, moving immediately to the right-hand column of
news. For the longest time, we could not figure out why these pages
would not work properly with a screen reader.
It turns out that the culprit is the time and date stamp! Because the
page is stamped for a continuously-updated time and date, it refreshes
with each click on an anchor link. For a sighted user, this quick refresh
is hardly noticeable. For the screen-reading software, it makes the
page unusable. The screen reader interprets the refresh as a new page.
Guideline 20. Use anchor links when a page has several
topics.
Guideline 21. Keep pages from refreshing when users
select an anchor link. Do not include a time and date stamp on a page
with anchor links.
-
Some screen-reader users jump from heading to heading.
Even on content pages, most sighted users don't read. They skim and
scan. If a document has lots of descriptive headings in bold or in
color, many sighted people use those to quickly get a sense of what
is in the document and to find a particular section. They only read
the few sentences that pertain to the specific topic they are looking
for.
On a page like this, most users scan
the headings first. |
(Note: This figure is not printed in the Interactions
article.)
Most screen reader users also want just the section that has the
information that they need. JAWS now allows them to skim through a
document as sighted users do, moving from heading to heading by pressing
H or using Insert-F6 to get a Headings List (just like a Links List).
Users who know about this feature like it very much. This is a new
feature in the latest version of JAWS and only a few of our participants
were familiar with it, but it is likely that others will learn of
it soon, and it may become as popular with screenreader users as the
Links List is for navigation pages. Window-Eyes plans to introduce
this feature in its next release.
Just as with the Links List, however, if many of the headings start
with the same words, screen reader users will be frustrated trying
to scan the headings with their ears. If the keywords they are looking
for are not at the beginning of the heading, they won't find the right
heading by jumping through the list with first letters.
Several of these headings start with
the same word. That makes it difficult for users to listen
quickly and find the one they want.
(The number after each heading indicates
the heading level.) |
(Note: This figure is not printed in the Interactions
article.)
Guideline 22. Encourage authors to use many headings
in their content and to be sure that those headings are clear, meaningful,
and parallel. This guideline is critical for both sighted users and screen-reader
users. (For more about writing useful headings, see http://www.usability.gov/design/writing4web.html.)
Guideline 23. Be sure that the headings are coded properly
in HTML, for example, as <H1> <H2>, etc. JAWS looks for the
heading tag.
Guideline 24. Put the keyword at the beginning of the
heading. If many headings are about the same thing, differentiate them
in meaningful ways.
Filling Out Forms
A major – and growing – use of Web sites is transactional;
part of our study involved observing users working with JAWS and Window-Eyes
as they tried to find and fill out forms.
-
First, screen-reader users must find the form.
The first problem that many participants had was finding the form.
Although JAWS allows users to find out if there is a form on the page
(with the Virtual Viewer) and to jump to the form by pressing F on
the page, none of our participants did that. They listened (scanning
with their ears) to the page until they got to the form – or
they gave up. When there was a lot of text on a page or the form was
far to the right, the form was hard to find. (Window-Eyes 4.2 has
no quick way to jump to a form; this feature will be in the next release.)
There's a lot to listen through on
this page before getting to the form. |
(Note: This figure is not printed in the Interactions
article.)
The form participants needed is way
down here. Several got sidetracked by links higher on the
page. |
(Note: This figure is not printed in the Interactions
article.)
Guideline 25. Do not put a lot of text on the same page
as a form.
Guideline 26. Do not put a form far down on the page
or far to the right.
Users do not want to switch back and forth between text and
fields.
Once they have found the form, users have to figure out what each field
is asking for. This can be much harder for screen-reader users than
for sighted users.
Screen-reader software must be modal. The program has to know whether
a key press is a command to control where it goes and how it reads or
is a letter that the user wants to type. The default mode is for reading.
Therefore, users must signal the program when they want to change to
typing (Edit) mode. Switching between modes for every field in a form
is annoying; users, understandably, don't want to do that.
As P10 explained: If the software does not read the label when you tab
to the field, "each time you've filled in a specific box, you hit
the plus key to go back to the virtual cursor and then down arrow to
make sure that you are getting all the information before you come to
the next field." Then you have to press Enter at the field to shift
to Edit mode. A form where you have to keep switching modes is not "well-behaved."
A well-behaved form is one where, as P10 says, "you don't have
to come in and out of the Edit mode."
A well-behaved form gives the screen-reader user all the information
to fill out a field within the field label that the user hears when
in Edit mode at the field. (See Figure 6.)
Children's Program Consumer Survey
In order to create the most productive programs possible, your
input and continuous communication is vital. Please take this
opportunity to fill out the enclosed survey so that we can ascertain
some of your current and future needs from the Columbia Lighthouse
for the Blind (CLB).
|
Figure 6. Example of a well-behaved form. After
filling in the Name field, the user presses Tab. The cursor moves to the
field box for Current address and JAWS says, "Tab. Current address
colon. Edit type text." The user fills out that box and presses Tab
again. The cursor moves to the next field box and JAWS says, "Tab.
Daytime phone number colon. Edit type text."
Most forms that our participants came across were not well-behaved. One
had done such a poor job that the tag for question seven was repeated
as the tag for question eight and question nine. An automated accessibility
checking program like Bobby would not have given the form a poor score;
Bobby only checks that the page has ALT tags, not that what is in them
makes sense to the user.
Guideline 27. Make sure that all fields are coded so
that users do not have to switch to and from Edit mode. Use the HTML [label]
element. To add more information than is in the label, use the Title attribute.
For more information on how to do this, see http://ncam.wgbh.org/publications/adm/index.html.
Guideline 28. In addition to checking your site with
an automated tool like Bobby or LIFT, listen to it with a screen reader.
-
If screen-reader users are in form-filling (Edit) mode, they
do not hear any text that is not part of a field.
Even when a form is well-behaved enough to read the labels with the
fields, other critical information may appear between the fields.
Screen-reader users who are tabbing from field to field will not hear
that information. (See Figure 7.)
Figure 7. Users listening to JAWS did not hear
"recommended or" and thus assumed they had to put in both
zip and state.
Users listening to JAWS did not hear
"or enter your state/province/region below if it is not
listed" and thus had no idea what to enter in the field
that has no label. |
(Note: This figure is not printed in the Interactions
article.)
Guideline 29. Do not put information between fields
on a form.
Guideline 30. If the user has an option of filling out
either of two fields, and they are mutually exclusive, inform the user
with the label of the first field.
Guideline 31. Do not exclude labels from fields.
When filling out a field makes the page refresh, the software
starts reading from the top as if it were a new page.
The same problem that we discussed under anchor links happens with forms.
One form that our participants worked with suggested putting in the
ZIP code first so that the form would return with at least part of the
address filled out. That's a time saver for sighted users, but it made
the page refresh so that the screen reader started over at the top of
the page.
If screen-reader users do this, the
page refreshes, and the screen reader starts at the top of
the page again. |
(Note: This figure is not printed in the Interactions
article.)
Guideline 32. Avoid making pages refresh.
Conclusions
Richard Rubenstein and Harry Hersh said some years ago about software
development [7, p. 29]:
In the absence of detailed information, we all work from assumptions
about who the user is, what he or she does, and what type of system
would meet his or her needs. Following these assumptions, we tend to
design for ourselves, not for other people.
This is as true of Web development as it is of software development.
As usability specialists, we know that, in most cases, neither we nor
the designers and developers we work with are truly representative of
even our sighted users. With very few exceptions, we as usability specialists
– and the Web designers and developers we work with – are
certainly not representative of our vision-impaired users. Observing,
listening to, and talking with representatives of the target audience
– in this case, users of screen readers – are critical.
To truly meet the needs of all users, it is not enough to have guidelines
that are based on technology. It is also necessary to understand the users
and how they work with their tools. For example, just realizing that vision-impaired
users do not listen to the entire page is critical for designing usable
pages for them. In this paper, we have developed guidelines for bringing
accessibility and usability together based on observing, listening to,
and talking with blind users as they work with Web sites and their screen
readers.
References
- Bobby – an automated checking program for compliance with Section
508. Available at http://webxact.watchfire.com
- Humphrey, T., How the Internet Is Improving the Lives of Americans
with Disabilities, The Harris Poll #30, June 2000. Available at http://harrisinteractive.com/harris_poll/printerfriend/index.asp?PID=93
- JAWS – a screen-reader. Available at www.freedomscientific.com
- LIFT – an automated checking program for compliance with Section
508. Available at http://www.usablenet.com/products_services/lift_dw/lift_dw.html
- National Center for Accessible Media, 2003, Making Educational Software
and Web Sites Accessible: Design Guidelines.
(See especially for guidelines on coding wellbehaved forms.)Available
at http://ncam.wgbh.org/publications/adm/index.html).
- President’s Committee on Employment of People with Disabilities,
now U. S. Department of Labor, Office of Disability Employment Policy,
Marketing to Customers with Disabilities, July 1997.
- Rubenstein, R. and Hersh, H., The Human Factor: Designing Computer
Systems for People, Digital Press, 1984.
- U. S. Department of the Census, Disabilities Affect One-Fifth
of All Americans, Census Brief, CENBR/97-5, Dec. 1997.
- Window-Eyes – a screen-reader. Available at www.gwmicro.com
- World Health Organization, statistics quoted in paper cited by the
IBM Accessibility Center at http://www-3.ibm.com/able/reasons.html (downloaded
in 2003).
- www.tiresias.org – a site
with information on many assistive devices for visionimpaired users
- www.usability.gov – a
site with links to resources about accessibility, guidelines for good
Web design, guidelines for writing for the web
- www.w3.org/WAI/ – the Web
Accessibility Initiative of the World Wide Web Consortium
Footnotes
1 © ACM, 2003. This is the author's version of the work.
It contains figures that were not included in the printed version for
lack of space. It is posted here by permission of ACM for your personal
use. Not for redistribution. The definitive version was published in
Interactions, Volume X, Issue 6, November-December 2003, pages 38-51,
http://portal.acm.org/citation.cfm?doid=947226.947227. Links updated
12/2006
If you are a member of ACM, you also have access to the online version
from Interactions in both HTML and PDF at http://www.acm.org/interactions/.
2 See http://www.section508.gov/ for links to the U. S. law,
the 508 standards, and other accessibility resources. See also the World
Wide Web Consortium Web Accessibility Initiative [W3C WAI] at http://www.w3.org/WAI/.
3 This paper reports on research with users who are blind
and use screen reader technology to interact with Web sites. We know that
there are many ways to use the Web depending on an individual’s
specific disability and that vision-impairment is only one of many disabilities.
We also recognize that we worked only with English-speaking people in
one part of the U.S. and that we are reporting here only on users who
use one assistive technology – screen readers. We are currently
working with users who have low-vision and use screen magnification software
to view Web sites, and we hope to report on the results of that study
soon. (2006 update: The study of people using screen magnification software
to work with web sites is published as Theofanos and Redish, Helping
low-vision and other users with web sites that meet their needs: Is one
site for all feasible? Technical Communication, 52 (1), February 2005,
9-20.)
Authors' version of Theofanos and Redish
Reprinted and expanded from Interactions, [X. 6],
November-December 2003, 38-51 |