Interaction Design

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.

During the design process, if you discover problems with your product design, you might consider applying the 80 percent solution—that is, designing your software to meet the needs of at least 80 percent of your users. This type of design typically favors simpler, more elegant approaches to problems.

If you try to design for the 20 percent of your target audience who are power users, your design may not be usable by the other 80 percent of users. Even though that smaller group of power users is likely to have good ideas for features, the majority of your user base may not think in the sameway. Involving a broad range of users in your design process can help you find the 80 percent solution.

Originally posted on Naar Voren

Je komt aan bij een groot warenhuis en in tegenstelling tot wat je verwacht staat er bij de grote draaideur een portier in een keurig pak. Je groet vriendelijk en wilt verder lopen. ‘Ho daar, wacht even’, zegt de portier. ‘U kunt zo maar niet naar binnen, want ik ga u helpen!’ Verrast als je bent, stamel je dat je komt voor een broek. ‘Prima!’, zegt de portier. ‘Wij hebben 49 soorten broeken.’ Tot je stomme verbazing gaat de portier alle soorten opnoemen. Bij ‘tuinbroek’ en ‘nette damespantalon’ onderbreek je hem en vertel je dat je dit geen helpen vindt. ‘Maar ik noem toch alle soorten broeken op die we hebben!’, zegt de portier. Je raakt wat geïrriteerd en zegt dat je misschien wel komt voor een witte spijkerbroek met roze knopen en scheuren. Dat zal hem leren, denk je. De portier vertrekt geen spier en zegt: ‘Die hebben we niet!’. ‘Geeft niet!’, zeg je. ‘Ik kijk wel even naar wat jullie wel hebben’. ‘Nee, dat kan niet, want uw vraag is niet voldoende gespecificeerd!’. Woest loop je weg om nooit weer terug te komen.

De portier staat voor de zoekbox, bekend van vele websites en vele applicaties. Hij is geduldig, maar nukkig. Het probleem is dat de zoekbox mensen helpt zoeken en dat mensen dat moeilijk kunnen. Waarom? Bezoekers van sites of gebruikers van applicaties weten vaak verschrikkelijk weinig over de informatieberg waarin ze zoeken. Ze weten bijvoorbeeld niet dat deze meestal is geïndexeerd. De belangrijkste woorden staan in een lijst. Als één van deze woorden wordt ingetikt in de zoekbox, dan geeft deze een lijst van documenten waarin dat woord voorkomt. Maar de zoeker beschikt niet over die lijst met geïndexeerde woorden. Hij of zij kan dus niet zien of het ingegeven zoekwoord bestaat in de lijst. Of dat het zoekwoord zo weinig discriminerend is dat je de hele informatieberg terugziet in de resultatenlijst. Dit betekent dat de resultaten van de zoektocht vaak niet goed zijn en de gebruiker ontmoedigd wordt.

Hoe ernstig dit probleem is zien we in een aantal bedrijfsstudies (o.a. IDC, 2001), waarin wordt aangegeven dat mensen tot 30% van hun werktijd bezig zijn met het zoeken naar informatie. Het duurt zo lang omdat mensen…

• Zoeken naar niet-bestaande informatie;
• Bestaande informatie niet kunnen vinden;
• Onvindbare informatie opnieuw maken.

In ecommerce studies blijkt (o.a. A.T. Kearny, 2001) dat 80% van de bezoekers afhaakt en de site verlaat omdat ze…

• Het gewenste product niet kunnen vinden;
• Een geselecteerd product niet besteld krijgen;
• Niet vertrouwd zijn met online creditcard transacties.

Vinden staat voor een ander soort benadering, een beetje klantvriendelijker. De portier heeft een cursus klantbenadering gehad. Hij stelt vragen als: ‘Wat voor soort broek had u gehad willen hebben: een meer moderne of een klassieke, nette broek?’. Als je het niet snapt, loopt hij met je mee en laat zien wat er is. De portier is een niet-opdringerige verkoper geworden die informatie over het aanbod gebruikt om je van dienst te zijn. De functie van deze portier zou ook uitgevoerd kunnen worden door een bewegwijzeringsysteem. Door middel van de juiste bordjes word je door het aanbod geloodst.

Een belangrijk verschil tussen de eerste en tweede portier is dat de tweede er niet vanuit gaat dat jij als bezoeker of klant veel weet over het aanbod. Hij gooit je dan ook niet in het diepe, maar helpt je door te komen met zo zinvol mogelijke opties. Op die manier ontstaat er vertrouwen in de portier en in de manier waarop hij je door de winkel laat lopen.

Zoeken leunt op kennis en initiatief van de klant, gebruiker, bezoeker. Dit leidt helaas in veel gevallen tot ontmoediging. Vinden daarentegen levert interactie tussen klant en aanbieder op. De klant maakt een selectie uit het aanbod op basis van zinvolle opties aangeboden door de aanbieder. Dit leidt vaker tot een bevredigende situatie voor vrager en aanbieder.

Het aanbieden van verschillende ingangen helpt bij het vinden van informatie op websites. De vaste indeling van een website, meestal te benaderen met het navigatiemenu, is onvoldoende: je mag niet verwachten dat je bezoeker precies op die manier tot de informatie komt. Het gebruik van trefwoordenlijsten, thesauri e.d. op websites biedt de mogelijkheid te anticiperen op de verschillen tussen de bezoekers: je geeft ze meer mogelijkheden om op hun eigen manier te vinden wat ze nodig hebben.

Er valt veel te leren van bibliotheken. De bibliotheek gebruikt trefwoordenlijsten, indices, thesauri, taxonomieën bij het aanbieden van informatie. Deze middelen vertellen de zoeker over het aanbod: wat is er, hoe is het gestructureerd, waar kun je het vinden. Het kenmerk van de middelen is dat er meerdere wegen leiden tot dezelfde informatie. Je kunt immers niet voorspellen met wat voor gedachte de zoeker in de bibliotheek komt.

Meerdere ingangen op dezelfde informatie leiden tot het vinden van informatie en producten. Door beter te kijken naar de zoekende mens die op je site komt, verhoog je de conversie van ‘zoeker’ naar ‘vinder’ en van ‘bezoeker’ naar ‘boeker’.

Read the whole story in this PDF: Interface Design Guidelines for Users of All Ages

• Thirty years from now, it is estimated one in four people in the developed world will be aged 65 and over, an increase from one in seven today.2 As the post World War II “baby boom” generation continues to advance in age, countries throughout the world will have more seniors than ever before.
• What is usability? Effective interface usability takes into account navigability, intuitiveness, functionality and sinteractivity from a user perspective, rather then the perceptions of the designer, developer or organization. All too often designers, developers and product marketers fail to understand the true human factor needs. What might appear as natural and intuitive to them may be confusing to the consumer.
• Accessibility refers to whether or not the technology allows end-users to make use of the technology. Just as technology skills and relevant content are integral components to bridging the digital divide for young and old, accessible design for people with disabilities is essential to making the Internet truly universal.
• We must not forget that for many the Internet is a new experience. We must not champion innovation over clarity or form over function. Users who are new to technology haven’t had the benefit of witnessing the evolution of site design and interactivity. Keep the cleverness where it belongs, in the content and put simplicity in the design.

Physiological Changes of Aging

After 55, many will experience vision changes including varying levels of presbyopia, experience a reduced field of vision and ability to resolve images. Other changes include an inability to distinguish certain colors and being able to adapt to changes in light levels as experienced when driving through a tunnel or walking out of a move theater.

Major changes in the changing eye:

1. The most familiar ailment is presbyopia resulting in the decreasing ability to focus on near tasks such as reading as a result of the eye’s lens losing its elasticity. While typically bifocals are designed for reading printed material at a distance 16” at a 25-30 degree downward angle, the average computer screen is 24” away with an upward viewing angle of 10-20 degrees. Many users with presbyopia find that a special pair of glasses optimized for computer usage resolve strain and fatigue.
2. Yellowing of the eye lens causes images to appear as if one is looking through a yellow veil or filter. Another result is that less violet light is registered by the eye, which makes it easier to see reds, oranges and yellows than it does to see blues, greens and violets. This loss in color perception is often called color blindness, which many as one in twelve males are affected. with. This affliction increases with diabetes as well as glaucoma,
3. A third major change in the aging eye is the shrinking of the pupil, resulting in the need for more light and a diminished capacity for adjusting to changing levels of illumination. According to the American Optometric Association, a 60 and 80 year-olds retina only receives 33% and 12% respectively of the light of an average 20 year old.

Layout & Style

• We have observed older users and novices tend to scroll much slower using the bar arrows on the right hand scroll bar, vs. dragging the bar. Further hampering their navigation is the use of an older mouse which does not have a built-in scroll wheel
• Users prefer rows and columns on page to be aligned and, as a result, are better able to read the text.
• Flashing or blinking graphics, Excessive pop-up windows and ads banners are highly distracting
• Using any background patterns including watermarks or embossed logos generally are distracting and interfere with readability. As an alternative, a light complementary background color can be applied.
• Large areas of white space and small blocks of text increase readability. It is suggested you leave a wide margin of 1 ½ or more inches on the right side of the page to maximize usability with different monitor types, window sizes and display resolutions.
• For those users with diminished motor capabilities, simple double-clicking a mouse or scrolling can be difficult. It is recommended you attempt to make all graphical links large and static. Increasing the size of the area around a link, making it “hot” or selectable, can enhance ease of use. Never expect a user to click on a moving graphic element or banner.
• When a user enlarges a Web page, images, including logos, banners and buttons, aren’t enlarged with the rest of the text on a page. Be wary of navigation bars and other crucial elements of a page that cannot be resized.
• Insure your links are consistently underlined to make then identifiable and so that “screen readers” can recognize them.
• Consistency in navigation is one of the golden rules for all designers.
• Left-hand alignment as used in this document, offers a high level of readability as compared to justification. Justified paragraphs have all lines the same length. Forcing the line length causes irregular letter and word spacing. Centered text is best used for titles or very small amounts of copy within a text box.

Color

• Complementary colors are opposite each other and provide contrast for readability. For example when choosing a primary color such as blue, its complementary color would be yellow. Adjacent colors to avoid would be orange and red or blue and green as they do not offer a high level of differentiation to the aging eye. An alternative choose colors from opposite side of the color wheel.
• It is usually in the low saturation levels (very pale or very dark) that cause difficulties for users with color deficiencies. Colors that are exceptionally bright, fluorescence or vibrant can have edges that appear to blur and create after-images, which fatigue the eye. For example yellow text is very difficult to read. A light type color on a dark background can cause letters to appear to close in itself.
• Do not use instructions which refer to objects by color. For example rather then telling the user to click on the red or green button, tell them to press the “on” or “stop” button.
• As a rule use dark type on light or white backgrounds.

Text

• Legibility (readibility) Use basic and common fonts. Avoid drop shadows on text. Use consistent typefaces and fonts throughout your site by applying style sheets, pre-setting formatting in body text, header, bullet and title applications.
• Size. Twelve to fourteen points are recommended font sizes for copy while headlines and titles are typically two points larger. Do not assume that all users know how to change their view or text size within their browser.
• Typefaces. Typefaces come in two general categories serif and san serif. Serif faces include extra “feet” at the ends of the strokes and vary in line weight within the shape of each letter. In general, for print applications, serif typefaces are most legible because the serif adds differentiation between letterforms. Yet, on lower resolution and small monitors, this may not always be true. Examples of serif fonts include Times New Roman as used in this document or Courier and Century Schoolbook. Sans Serif (without serifs) includes fonts such as Arial and Verdana. Choose typefaces based on their familiarity and legibility.
• Kerning. Kerning refers to the adjustment of space between letters in a word.
• Leading. The space between each line of text. Typically, the leading specified is 2 points
  larger than the typeface.
• Use of all capital letters. While there is a need to delineate content from headings, the use of all caps tends to lead to higher levels of eye fatigue because of little differentiation between the letters. As an alternative, consider using bold or capitalize the first letter of each word in a heading. This provides contrast from the body copy, will increased readability. For example “A Guide for Effective Web Design for Users of All Ages” vs. “A GUIDE FOR EFFECTIVE WEB DESIGN FOR USERS OF ALL AGES”.
• Alt Tags. Insure every graphic element, logo and photo includes an “ALT tag”, using alt= “…”. Insure the description is concise yet descriptive, for someone who may not be able to see the image but uses a screen reader or voice synthesis browser, or does not have the ability to download graphic images.
• About Us. The About Us section of your site is important to the older computer and Internet users as they are often concerned of potential information and privacy misue.

Complemtary colour wheel:
Complementary colours are the best choice to provide contrast for readability