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, to the Web Accessibility Working Group (WAWG), and to other U-M personnel by request. Please send comments or questions to Jane Vincent, Assistive Technology Lead, .
Skip-nav links make website navigation more efficient for people who navigate the Internet using keyboard commands instead of a mouse, including screen reader users and some individuals with dexterity disabilities. These users generally navigate in a linear fashion--pressing keys to move from one link to the next or the previous link. They will likely find it onerous to have to navigate through long lists of repetitive links, such as those on the left side of many pages, to get the content of interest. A skip-nav link, usually phrased as something like 'Skip to main content,' allow users to bypass such lists and go directly to the main page content. Where needed, it should ideally be the first link on the page, or at least one of the earliest links.
The WebAIM website provides several techniques for creating skip-nav links. The most elegant of these, balancing utility for people who need these links and aesthetics for those who don't, is one that keeps the skip-nav link hidden until it gains keyboard focus when the non-mouse user navigates to it.
There have been lively discussions on the WebAIM listserv about using multiple skip-nav links to guide people to different parts of the page. The general consensus was that multiple links should be used rarely and sparingly, otherwise they contribute to rather than address the navigation problem. There were also suggestions that use of proper heading markup is also an effective strategy, with the acknowledgement that this is only helpful to screen reader users.
By no small coincidence: coming up in our 5/24 issue, a Refresher on heading markup
My team just put a lot of effort into making sure our website meets accessibility standards, including soliciting input from assistive technology users. This resulted generation of a lot of information about using keyboard shortcuts, using browser zoom features, etc. How do I communicate this information to the people who will need it?
Excellent question. The most common strategy is to provide an 'Accessibility' link to a page with this information, preferably near the top of the page (perhaps right after a skip-nav link). The page should include as much of the following information as possible:
Coming up in our 5/24 issue: How can I code pages for compatibility with speech input software?
Since I only received one response to these questions, I'm running this again. Let us know your best ideas!
Background: Below are examples of offbeat 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 21. 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?
One of the nice features of using the Windows screenreader NDVA to review page accessibility is that it has an option to show a redundant visual version of what it's saying (see the 10/12/12 newsletter for details). However, it's still useful to be able to also hear what's happening, so that you can catch some issues before turning over the testing to a screen reader user.
If you don't like the default NVDA voice, there are a variety of options to choose from. Right-click on the NVDA icon in the toolbar, or in the 'Show Hidden Icons' menu. Choose Preferences-->Voice Settings, and pull down the Variant list in the resulting dialogue. Most of the voices are fairly low-quality; klatt3 and female2 are two that I find to be better than average. Note that there is also a Voice option that lets you choose the language.
If you are going to be doing a significant amount of testing, you may want to install a higher quality voice. NVDA maintains a list of third-party voices, several of which are available for free.
Coming up in our 5/24 issue: Is ChromeVox useful for testing?
For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent, John Cady