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, .
The Web Content Accessibility Guidelines (WCAG) 2.0 document specifies three levels of conformance: Level A, Level AA, and Level AAA. Each of these levels is associated with successful adherence to specific guidelines within WCAG:
WCAG 2.0 documentation notes that 'It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA Success Criteria for some content.' However, Level AAA guidelines often cover design features that dovetail with general usability principles, such as creating site navigation strategies, helping users prevent errors, and writing using clear language. Even if you decide to conform to Level A or AA, you may still want to include some Level AAA guidelines in your accessibility plan.
Coming up in our 3/22 issue: a Refresher on use of LANG attributes
I've heard that 'complex tables' can cause accessibility problems. What kind of tables are considered complex, and how can they be made accessible?
Table complexity is usually judged by the number of levels of header structure. For example, the following table would be considered simple--one level each of column and row headers:
|Year||Highest Football Scorer||Highest Basketball Scorer|
|2012||B. Gibbons||T. Burke|
|2011||D. Robinson||T. Burke|
This table, however, adds a second level of header structure, making it more complex for screen reader technology to correctly interpret:
|2012||B. Gibbons||T. Burke|
|2011||D. Robinson||T. Burke|
Often, the best solution is to review the table and see if it can be reorganized into a simple table or split into multiple tables. If a table with two levels is necessary, there are ways to use HTML markup (ID and HEADERS attributes) to provide accessibility; however, this requires adding markup to every cell. The Penn State AccessAbility site has links to examples of complex table markup. Use of tables with three or more levels is discouraged.
Coming up in our 3/22 issue: Fixed vs. adjustable font definitions--how do they affect accessibility?
Background: Color contrast presents a good example of where accessibility best practices improve overall usability. Small gray text with a white background, for example, is going to be hard to read for most people regardless of visual acuity, and yet it remains a common web page design feature.
Color contrast is measured using a contrast ratio, a mathematical formula that compares the relative luminosity (brightness) of the text and background colors. The minimum possible ratio is 1:1, which would occur in the unlikely case that the background and text colors are identical. The maximum luminosity difference is between white and black, which has a ratio of 21:1. Note that it does not matter whether the background or text are darker; in fact, many people prefer a dark background and light text.
WCAG 2.0 success criterion 1.4.3 (Level AA) states that all text/background combinations should have a contrast ratio of at least 4.5:1, with three exceptions:
(The first four examples were generated using Lea Verou's Contrast Ratio tool)
Contrast Ratio 2:1. Neither the large or standard print pass 1.4.3.
Contrast Ratio 3.9:1. The large type passes 1.4.3; the standard type does not.
Contrast Ratio 4.8:1. The large type passes 1.4.3 by a safe margin; the standard type barely passes.
Contrast Ratio 9.4:1. Both type sizes easily pass 1.4.3.
The white 'Hello world' caption has a contrast ratio of 2.5:1 against the light gray background, which fails regardless of type size. (Making the text black would have a ratio of 7.4:1, which passes easily.) The 'Shoe-Inn' text has a ratio of 3.3:1, but can be considered text that doesn't need to be read and therefore doesn't need to meet contrast standards.
The white 'University of Michigan' text and the block M both have passing ratios (8.7:1 and 6:1, respectively), even though this is a logo and has no contrast requirements.
For each of the images below, determine whether the color contrast passes WCAG success criterion 1.4.3.
Answer: Contrast fails, and would fail even if the text were larger.
Answer: This is a logo, so it has no contrast requirements.
3. Ratio=3.2:1 (Hint: The larger text is 20 pt.)
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.
Question: How would you modify the following link names so that they would communicate appropriate information when read out of context?
1. (the 'Read More' link)
2. (the 'here' link)
3. (both Help links)
AChecker is a tool that does a thorough accessibility review of website code and presents results with detailed information about where problems occur and what the most likely fixes would be.
By default, AChecker presents results sorted by guideline, so that all similar problems--e.g., missing or questionable ALT attributes--are grouped together. However, it's also possible to have the results sorted by line number. This latter may be more convenient for the people maintaining the pages, since it lets them go through the page in a linear fashion.
To choose a sorting option, and also to choose what guidelines are used to generate the report, click on the Options link at the center left of the page.
A list of options will appear, including radio buttons for 'View by Guideline' and 'View by Line Number.' Choose the options you want, then click on the Options link again to confirm your choices.
Coming up in our 3/22 issue: A handy chart for evaluating ALT attributes
U-M Accessibility Heroes: Technology Services, Division of Student Affairs
As a new feature, we will be commending individuals and groups on campus who are making a positive impact on web accessibility at U-M. Please send your nominations to Jane, firstname.lastname@example.org.
Technology Services creates templates for many of the student-facing pages on campus, including the pages for the Office of Services for Students with Disabilities (SSD). Accessibility features that they have implemented include a 'Pause' button to make it easy for assistive technology users to control the information carousels. They are also working with the SSD office to make ongoing improvements to the way that information is communicated online to students with disabilities. We commend George DiGiacomo, Edith Andrew, and the Technology Services team for their attention to accessibility!
For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent