Read the whole article on Usability News

EYE TRACKING RESEARCH
Using technology which records minute eye movements, a number of researchers have carried out studies into web usability and accessibility
Experts including Jakob Nielsen and the Poynter Institute are amongst those who lead the way in this field. These key findings might help your organisation to improve the design of your website, in turn ensuring its accessibility and usability:
- Nielsen has found that only 16 per cent of users read a page word by word – most users will scan, letting their eyes flit over areas of interest before going back and reading areas of interest in more detail.
- So, a thoughtlessly designed page, with distracting pictures or links within the text is like an obstacle course, leading visitors off the course of the page they have visited.
- Web pages are often read in an F or E pattern, with users more likely to read longer sentences at the top of a page and less as they scroll down.
- Users are excellent at blocking out what they don’t want to view – this includes some pictures and banner advertising where they don’t want to see it.
- Pictures are not always eye catching – they can often be ignored. Good images should provide useful information which links into the text. Users respond best to real people rather than models, and subjects who look directly into the camera.
- The top left of a web page is a ‘hotspot’, which attracts most viewing from visitors. The far right columns and bottom section are the least viewed areas.
- To grab users’ attention, you should use relevant snappy headers and blurbs, and use half the amount of text which you would in non-web writing. Longer paragraphs seem to discourage viewing – even one sentence paragraphs are fine.
- One column layouts perform better in viewing tests – users seem to be more used to this standard and simple format.

QR Codes
The inclusion of QR Code reading software on camera phones in Japan has led to a wide variety of new, consumeroriented applications, aimed at relieving the user of the tedious task of entering data into their mobile phone. QR Codes storing addresses and URLS are becoming increasingly common in magazines and advertisements in Japan. The addition of QR Codes on business cards is also becoming common, greatly simplifying the task of entering the personal details of a new acquaintance into the address book of one’s mobile phone.

Ruben Timmerman schrijft op zijn weblog usarchy over de trucs die worden toegepast bij reclames en afsluitprocessen van SMS Diensten. Los van het feit dat de methodes onethisch zijn, kunnen we er wel wat van leren:

• Trek bezoekers op sites waar ze al met een vergelijkbaar proces of dienst bezig zijn.
• Gebruik grote merken om je betrouwbaarheid op te krikken. Zij gebruiken Apple, voor je webshop gebruik je iconen van TNT post, Thuiswinkel.org, iDeal en Mastercard.
• Geef op de landingspagina liefst maar 1 call to action, zodat het duidelijk is wat de bezoeker moet doen.
• Probeer niet direct te verkopen, maar sleep eerst een zachte, gratis, conversie binnen.
• Bied geen enkele afleiding tijdens het conversieproces, en als dat moet, zet het dan onder de vouw.
• Creëer een “sense of urgency” door woordgebruik om NU te converteren.
• Maak de call to action overduidelijk door 3d effect en opvallende kleur.
• Vraag alleen het strikt noodzakelijke dat nodig is om de conversie te begaan.
• Noem eerst de benefits voor de gebruiker en pas later de kosten. Hou die twee zo ver mogelijk uit elkaar (lees ook marketingguru Seth Godin hierover):

I just watched this great video by Ryan Singer (37 Signals) about Web Application Usablility. I wrote this summary:

When creating a page keep in mind the hierarchy of elements. Pages that are well structured and prioritised naturally create esthetic layouts. It works good so it feels good.

A page consists roughly of three object types:
1. Things that pop out (strong)
2. Things that belong to the basics (normal)
3. Things that need minor attention (weak)

Optical gradient
Things that need minor attention can have a smaller font and more opacity (grey text). In this way you create a ‘optical’ gradient, the eye will move from the bigger, stronger parts to the smaller, less visible parts. This created contrast helps the user to distinguish important from less important content. Also, contrast by headers, bold text, smaller text, highlighted menu items, links etc. serve as the handles we use to scan a page. They give the user control over the page.

Create handles
Create handles that hold the site. For instance: big headers, outlined text, an image or a (navigation) stroke.

Create importance levels, also in one line
When interface-elements look exactly the same it only means that the design decided they are all equally important. Here two things mather: 1. Which features are used the most by the visitors and 2. Which features do we want them to use. However, we should emphasize more important features, e.g. by greying ot this additional info. Also, we should de-emphasize additional info behind certain elements. By doing this we don’t bother the user with this info while he is scanning a page. If he’s interested in a an option, he’ll read on.

It all comes down to
1. Decide what matters
2. Make that pop out
3. Make everything else fade back

On the Dutch site MarketingFacts this article was posted about designing websites for older people. Below you find a short abstract. Visit MarketingFacts for the whole article.

Facts:

• In 2040 there will be aproximately 4 millions 65+ people in The Netherlands.
• According to research by Jacob Nielssen the time to complete a online task increases with 0.8 percent each year. So a 40-year-old needs 8% more time to complete a task then a 30-year-old.

3 reasons why older people are less likely to use computers:

• They aren’t motivated enough and don’t see why they should use computers.
• Lack of computer experience
• Physical constraints (reduceed sight)

So how can u make sure older people can use your site?

• Bigger navigation menu’s and action buttons. Also, mouse-over effects encourage clicking
• Use sans-serif fonts like Helvetica, Arial and Verdana with font size 12 or 14
• Use a line distance of 1,5 to increase text readability
• Don’t use many images and icons because they distract too much. Make use of descriptive icons.
• Use bread crumbs
• Use bold for important words.
• Avoid fly-outmenu’s.
• Use search with ‘auto-suggest’ too avoid spelling errors.

Based on the Dutch article 10 tips: maak van landingspagina’s een succes on Frankwatching.

Optimization of your campaign’s or se4rch action’s landingspage is essential for a high conversion (to the end-goal, for instance generating a sale or lead). 10 tips to be succesfull:

1. Define a concrete goal: what is the kpi (key performance indicator) of your campaign? Say you pay 0.10 cents per click for a Google Adwords campaign. You have 1000 people that click. Then you pay 100 dollar. Say you have a conversion of 0.2 %. That means that 2 people become a lead/buy your product. Then you paid 50 dollar per lead. Is this worth it? Is 50 dollar per lead an acceptable kpi for you? Define it and make (technically) sure you measure it.

2. Point out specific landings page. If you link to a productpage, make sure you optimize that page (leave out distracting info etc.). Never link to your homepage. Monitor which pages are frequently entered via search engines and optimize these pages.

3. Be sure you make a good first impression. Make it visually attractive.

4. Be sure your landingspage and campaign teasers (posters/banners/tv ads etc.) are visually and textual in line with eachother. People search for recognition and come for that one specific thing that they were teased by/that they were promised.

5. Minimize distraction. Make sure they reach the desired goal, increase conversion. Consider leaving out the main navigation or side navigation bars etc.

6. Create one clear call to action. Make sure it’s above the fold.

7. Communicate your claim (your campaign’s pay-off) on a prominent position.

8. Write short, effective copy. Use bullets to sum up features and advantages.

9. Gain your visitor’s confidence. Give guarantees/contact info close to the ‘buy’ button.

10. Keep measuring and improving.

Lewin’s equation:

Lewin’s Equation, B = f (P,E) ( B – Behaviour; f – Function; P – Person; E – Environment ), …

… is a psychological equation of behaviour developed by Kurt Lewin. It states that behaviour is a function of the person and his or her environment.

There is a desired behaviour that we need to encourage, but we have no control over the person, so via interaction design, information architecture and interface design we control the environment and therefore generate the desired behavior.

Read more about UXD in this great article on boxesandarrows.com

Taakmodellen kunnen door een ontwerpteam worden gebruikt als uitgangspunt voor het ontwerp. Ze betreffen alle informatie over huidige en te verwachten toekomstige ‘context of use’: wie gebruikt technologie, voor welke activiteiten (taken) met welke doelen, in welke situatie? Als ontwerper zijn dit de eerste vragen die je moet stellen, en je moet je steeds afvragen in hoeverre jouw ontwerp een verandering op deze gebieden veronderstelt, of veroorzaakt.

Originally posted on
Digital Design Blog

It’s a truism that important content, the content you want users to focus on, should appear “above the fold.” Does this mean that all content should be crammed into this valuable real estate? Should all content be designed to be consumed in one-screen chunks? The key to answering these design questions lies in understanding user scrolling behavior. Unfortunately, scrolling is one metric that is rarely reported on in the growing Web analytics industry and consequently, understanding how users explore long pages of content can be a mystery.

Within our Site Optimization practice, scrolling data is one of many behaviors we collect and interpret to inform the design recommendations we develop for our clients. We use scrolling data to answer three fundamentals questions:

1) Do users scroll

2) Do they scroll before they do anything else

3) How much do they scroll

These three questions provide a wealth of insight into content exposure and whether or not one-screen chunks are the best way to parse information on a given website.

Looking at a variety of “long” pages from publishers and eCommerce sites (pages in which more than half of the content is below the fold) we found that indeed, users do scroll. In fact, on average more than two-thirds of users on these pages scroll. Furthermore, nearly 75% of these users scroll before they do anything else on the page. What does this mean? Users can’t help but scan a page. They aren’t necessarily reading every word, but they are skimming, looking for that bit of content that piques their interest — a hot headline or that fancy phone the person next to them on the train this morning was busy texting away on.

But this is only part of the story. Yes, users are scrolling and skimming content and the fold isn’t a cliff which stops users in their tracks. Rather, the fold marks the top of a gradual hill. This gradual drop-off becomes readily apparent when we look at how much of the screen users view by scrolling. We find that most users scroll to about 50% of the page’s length. Interestingly, we’ve found there are some differences in how far down the page these users scroll on publisher pages versus product pages. For example, on average, users on publisher pages scroll to view about 40% of a page, while users on product pages scroll to view about 60% of a page (see chart).

While placing valuable content above the fold is a best practice, most users will be exposed to content halfway down the page. And users who are motivated to scroll farther are often more qualified users.

By understanding users’ scanning behavior one can make better decisions about content placement. And the answer to the question of “do they or don’t they” on a given site may be that only an advanced analytics team knows for sure.

Originally posted on Redish.net.

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:

1. 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.
2. 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!
3. 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.
4. 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].
5. 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.
6. 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]. ³

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

1. 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.

1. 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.

1. 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.

1. 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.

1. 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?

1. 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.”

1. 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.

• • Literacy – What is it?
  • Volunteering – Where can I volunteer to work with adult learners?

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:

Guideline 14. Start question headings with a keyword followed by the question.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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.

1. 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). Name: Current Address: Daytime phone number:

   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.

1. 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.

1. 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.