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: Starting with the April 12 issue, we are planning to send out emails with a link to an HTML version of the new newsletter. If you would prefer to continue receiving the entire newsletter via email, please let Jane know.
LANG attributes provide information about the primary language used within a website and any major shifts to other languages. From an accessibility perspective, inclusion of LANG attributes ensures that screen readers used by blind individuals and text-to-speech software used by individuals with learning or cognitive disabilities will speak information using appropriate pronunciation rules.
LANG attributes should be added in two places:
A list of language codes for use as part of a language attribute is maintained by the International Standards Organization (ISO).
Coming up in our 4/12 issue: a Refresher on keyboard focus
I understand that adjustable font definitions were important for old versions of browsers, particularly Internet Explorer. But aren't they obsolete, now that IE has a Zoom feature like other browsers?
WCAG 2.0 Success Criterion 1.4.4 states, 'Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality.' Part of this criterion includes defining font-size properties using adjustable font measurements--em units, named font sizes (e.g., 'larger'), or percent--instead of the fixed measurements pt and px.
It is true that a Zoom feature, which enlarges everything on the page, is helpful to many people. However, others are best accommodated by having only the text enlarged by using the Text Size feature in IE or the Zoom Text Only feature in Firefox. For these users, it is still necessary to use adjustable measurements for their preferred features to work. Including these font definitions in an external cascading style sheet (CSS) ensures that changes to multiple pages can be made by simply updating the CSS.
Incidentally, if you have been using fixed measurements and wish to convert them, webSemantics has a handy conversion chart for fonts up to 36 pt.
Coming up in our 4/12 issue: What are keyboard traps, and how can they be avoided?
Background: One strategy that screen reader users often employ to get an overview of a page is to extract all the page links into a separate list. However, links are often written so that they don't make sense when extracted. If a user hears 'Click here,' or 'More,' in most cases they will have no context from which to determine what information they will access if they select the link.
WCAG Success Criterion 2.4.4 says, 'The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.' The easiest way to meet this criterion is to create link names that provide just enough information to convey the link's purpose when accessed out of context.
How would you modify the following link names so that they would communicate appropriate information when read out of context?
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:
A good rule of thumb is to have the page title equal the <h1> heading, plus information indicating the main purpose or owner of the site where relevant. For example:
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:
1. Title is 'Tech Transfer :: Resources :: Industry,' which is also the title used for other pages listed in the 'More Industry Links' section.
2. Title is 'Joyce Marcus | Museum of Anthropology | University of Michigan'
3. Title is 'Services | MUTO'
Meeting the letter of WCAG Guideline 1.1 by adding a text equivalent in HTML (usually via an ALT attribute in an IMG tag) is fairly easy; meeting the spirit can be much tougher. Frequently, text equivalents are either too long--a detailed description of an invisible space, for example, which should take a null text equivalent (ALT='')--or too short--such as a detailed pie chart with the equivalent ALT='Pie Chart.'
Dey Alexander, a web design consultant in Melbourne, has done a brilliant job in the flow chart below to summarize professional consensus about writing text equivalents:
Coming up in our 4/12 issue: Selecting browsers to use for testing
For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent