University of Michigan

Accessibility Testing Newsletter > 04.26.2013

All Newsletters

The Accessibility Testing Newsletter is a twice-monthly publication (second and fourth Fridays) intended to supplement training provided through the Accessible Apps project. It will contain information of use to both programmers and non-programmers. The Newsletter is sent automatically to AIS staff, and to other U-M personnel by request. Please send comments or questions to Jane Vincent, Assistive Technology Lead, jbvincen@umich.edu.

(It wasn't your imagination: there was no newsletter the week of April 12. Thanks for your patience--we're baaaa-aaaack...)

Refresher: Keyboard Focus

If you're a mouse user, you usually don't care what object has the onscreen focus at any given time: you can use the mouse to click on any area to move the focus where you want it to go. Screen reader users get clear audio feedback about where the focus is located. However, if you're a sighted person who uses keyboard commands instead of a mouse, it becomes very important to get a visual indicator of where the focus is. Otherwise, you may issue a keyboard command that navigates you to the wrong page, or worse.

WCAG Success Criterion 2.4.7 (Level AA) states, 'Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.' Keyboard focus is usually indicated using a dotted line around the interactive item (the exception is the familiar cursor bar within a field that accepts text entry). In the example screenshot from the U-M home page below, the focus indicator is on the link to the article about Charles Munger:

Screenshot of U-M News and Events page with focus indicator on article link beginning 'Charles Munger pledges $110 million'

The main reason the dotted line may not appear is use of a CSS reset file that includes code removing the focus indicator. If you are doing testing and find that focus is absent, look at the CSS or ask the programmer if they used a reset file.

Coming up in our 5/10 issue: a Refresher on skip-nav links

Problem of the Week: Keyboard Traps, and How to Avoid Them

I just got a call from a student who said she uses keyboard commands instead of the mouse to navigate the screen. She said that she's able to move the focus into a form field, but then can't move out of it without reloading the page and losing what she's already entered. What could be causing this?

Answer: This is called a 'keyboard trap.' It's a relatively uncommon issue, but it gets its own Level A WCAG success criterion, 2.1.2: 'If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.'

According to the NoMensa 'Humanizing Technology' blog, keyboard traps are cause by Javascript 'if blur or any keypress events are used to enhance or override an elements behavior.' They suggest three possible fixes:

Coming up in our 5/10 issue: My page has great accessibility features. How do I let users know?

Answer to 3/22 Quiz Question: Page Titles

Background: WCAG Success Criterion 2.4.2 discusses providing page titles (using the TITLE tag within the HEAD section) that give an efficient and meaningful indication of the page content. This is a particularly helpful navigation aid for screen reader users, since the page title is the first thing that they will hear when they land on a new page.

Common examples of page titles that violate this guideline include the following:

Examples:

Screenshot of Faculty A-Z page within Michigan Law School web site.

This page has the title 'Faculty by Category' but is actually an alphabetic list. 'Faculty A-Z' or 'Faculty by Last Name' would be more accurate. Incidentally, since students may be browsing multiple departments, it would be useful to include the department name at the end of the title: 'Faculty A-Z | Law School, University of Michigan'

Screenshot of Mental Health Work Group web page, 'For Students' section of site.

This page is one level into the Mental Health Work Group site, but it has the same title ('Mental Health Work Group') as the home page and several other site pages. It should have a descriptive and unique name, such as 'For Students | Mental Health Work Group'

Screenshot of Treatment and Clinical Trials web page within Stem Cell Research web site.

This page has the title 'University of Michigan Stem Cell Research | Treatment and Clinical Trials,' which is fine. A horizontal line (Shift + \) or a pair of colons (::) are commonly used to separate the main purpose of the site ('University of Michigan Stem Cell Research') and the title of the specific page ('Treatment and Clinical Trials'). Use of two separators (e.g., 'University of Michigan | Stem Cell Research | Treatment and Clinical Trials') would also be OK.

Question:

Determine whether the following page titles are appropriate and, if not, what would be better:

Screenshot of Connecting with U-M Faculty and Researchers page within Office of Technology Transfer web site, within Industry sub-section and Resources section.
  1. Title is 'Tech Transfer :: Resources :: Industry,' which is also the title used for other pages listed in the 'More Industry Links' section.
    • Answer: Change the title to something like 'Tech Transfer :: Connecting with Faculty and Researchers

    • Screenshot of Joyce Marcus web page within University of Michigan Museum of Anthropology site.'
  2. Title is 'Joyce Marcus | Museum of Anthropology | University of Michigan'
    Screenshot of Services web page within Michigan Union Ticket Office site.'
    • Answer: This title is fine as is.

  3. Title is 'Services | MUTO'
    • Answer: Because screen reader users may hear a pronunciation of a nonsense word such as 'Mootoe' or 'Mutto,' and other users may not know what the acronym stands for, it should be spelled out: 'Services | Michigan Union Ticket Office'

4/12 Quiz Question: Troubleshooting

Background: We're going to do something different for this quiz question. Below are examples of actual electronic accessibility problems. Your challenge will be to come up with one or more potential fixes, and email your ideas to Jane (jbvincen@umich.edu) by May 7. Whoever has the most effective and/or creative answer for each problem will receive eternal fame...and something else. 8-)

Problem 1: A user with low vision opened the last Newsletter in Google Mail and finds that it contains several very wide graphics. The user reported that, 'Google Mail in the Chrome browser picks [the width of the graphic] as the width of the text-display, however my monitor is not that wide. Therefore, for each line, I need to scroll right and left in order to see the whole thing.' How can this be fixed so that the user doesn't need to scroll?

Problem 2: A client insists that you use #B36F0B as a site background color. You test it for color contrast with the two extremes of text color: white (#FFFFFF) and black (#000000). White fails by a significant, although not huge, margin: it has a contrast ratio of 4.04:1 for regular size text, where the passing ratio is 4.5:1. Black passes with a contrast ratio of 5.2:1, but several users complain that it's hard to read. What would you suggest?

Image with brown background, 'Welcome to my gingerbread house!' in white text, 'Welcome to my gingerbread house!' in black text

Problem 3: A home web page is missing an <h1> heading, which is important for letting blind users know the main purpose of the page they are on. There is no body text to which the <h1> can be assigned. However, the page has a logo and a menu bar. How might <h1> information be appropriately included?

Evaluation Tool Tip: Selecting Browsers to Use for Testing

Web accessibility testing usually involves taking several variables into account. One of these is the browser: which kind, which version, which platform? Things to consider include the following:

If there are clear results indicating that there are preferred browser to use with specific applications and assistive technologies, it will be helpful to note this in accessibility documentation or other prominent place on the site.

Coming up in our 5/10 issue: Changing voices in NVDA

For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent, John Cady