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, .
Note: The next newsletter will be sent out on January 11. Happy holidays!
Keyboard commands (also known as 'keyboard shortcuts') are a replacement for some or all mouse functions within a given application. They are used extensively by anyone who finds mouse use difficult or impossible, including individuals with visual and dexterity disabilities. Because they frequently offer more precision than mouse control, keyboard commands can be popular among non-disabled users as well. The downside is that extensive or exclusive use of keyboard shortcuts requires a great deal of memorization.
Some keyboard commands are built into the operating system; for example, in Windows 7 it's possible to press Ctrl+Esc from almost anywhere and bring up the Start menu. Others are built into specific programs--many programs use C, X, and V in conjunction with the Control or Command key as the keyboard shortcuts for Copy, Cut, and Paste, respectively. Still others may be built into assistive technologies; screen readers in particular include many keyboard shortcuts for controlling navigation and audio playback. Because of their ubiquity, keyboard shortcuts need to be defined carefully to avoid conflicts with the OS and other programs.
Lists of common commands are available for most operating systems, including Windows 7, Windows 8, and Mountain Lion. Applications often have a section in their 'Help' documentation that lists their keyboard commands.
Coming up in our 1/11 issue: a Refresher on how speech input works with interactive items.
Someone told me not to use layout tables for page formatting, but admitted that they based this on old information. Is this still true
Answer: Yes and no. Screen readers users should be able to assume that information will either be read in the correct order (left-to-right, top-to-bottom, and across one column before starting the next), or that markup is used to cue the screen reader about any order variation.
Simple layout tables should allow a correct reading order by default. However, if markup or unusual visual placement has been used to create specific effects, the reading order may be inaccurate. A layout table that organizes information in columns instead of rows, such as the following...
will be read by a screen reader as 'I register about what wish a this I to complaint parrot bought,' unless some type of markup is used to specify a different order.
You can use the free WAVE toolbar for Firefox to see the order in which a screen reader will access a table (click on the 'Structure/Order' link). For example, this simple layout table from ironspider.ca should be read correctly based on the WAVE results...
Improper reading order can be addressed either through use of the tabindex attribute (not recommended) or by using CSS to format the page.
For a more technical discussion of this issue, see the WebAIM article on Creating Accessible Tables.
Coming up in our 1/11 issue: Do I always have to avoid using links with the same name but different destinations?
Background: Since there is no auditory equivalent of a glance, screen reader users are dependent on HTML markup to provide clues about the structure of a given page. A popular strategy involves using heading tags <h1> through <h6> to convey a sense of information hierarchy within the page. Indeed, a 2012 survey of screen reader users found that nearly half found that navigating a page using heading tags was 'very useful,' and another 35% found it 'somewhat useful.'
For heading tag markup to be meaningful, the following best practices are useful:
Example: When the WAVE accessibility checker is used on the U-M Office of Technology Transfer home page, it shows that the only two headings on the page are the <h2> associated with the picture on the left, and the <h3> for 'News and Events' on the right.
Question: What two heading rules does this page break?
Question: What two heading rules does this page break?
We're not quite done with this example--see this issue's quiz question below.
Background: Creating appropriate text equivalents is tricky for most graphics. A balance needs to be struck between providing a screen reader user with enough information to understand the page but not so much extraneous information that it takes an inordinate amount of time to review the page.
For photos, creating a good text equivalent can be particularly complex. Many photos are used for decorative purposes; it's possible to understand the site without knowing the photo content. However, some screen reader users argue that they like hearing about a photo as a way of breaking up the text they are listening to, in the same way that sighted people like the visual diversion photos provide. There is no consensus among screen reader users as to whether decorative photos should be described or should take a null text alternative (ALT='').
If a text alternative is used, a good goal would be to provide a short, meaningful description that adds flavor but doesn't distract from the page's purpose. The graphic below might be described as 'Chris playing his guitar':
Example: Take a close look at the photo from the Tech Transfer page above. The 'Celebrate Invention 2012' information is echoed in a caption below the page, so that doesn't need to be included in the text equivalent.
Question: Which of the following would be the most appropriate text equivalent?
A. 'Attendees at the Celebrate Invention conference standing near the Arborlight, LLC booth. A man at this booth is speaking to two other men. The crowd includes several bald men, including one near the bottom right corner who has a beard and mustache and is smiling'
B. 'People visiting booths at the Celebrate Invention meeting'
C. 'Photo of people'
Most assistive technologies assume that web pages they are reading use valid HTML. When this isn't the case, assistive technologies may not work properly, frustrating their users. Fortunately, checking for HTML validity can be done quickly. Free validators such as the W3C Markup Validation Service provide reports that can be handed to programmers for handling. Be aware that these reports are usually overly fussy; changing one piece of code often fixes multiple reported items.
Coming up in our 1/11 issue: Tips on performing keyboard-only testing.
For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent