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, .
(It wasn't your imagination: there was no newsletter the week of April 12. Thanks for your patience--we're baaaa-aaaack...)
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:
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
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.'
Coming up in our 5/10 issue: My page has great accessibility features. How do I let users know?
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:
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'
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'
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.
Determine whether the following page titles are appropriate and, if not, what would be better:
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 (firstname.lastname@example.org) 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?
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?
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