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, .
There can be a significant difference in how form labels are interpreted by sighted people and by screen reader software used by blind people. When encountering the example below, a sighted person would likely assume that 'Put text here' was the label for the text field it is above. However, a screen reader would be likely to read 'Don't use this! form field,' causing confusion and increasing the likelihood of error.
To eliminate this confusion, markup can be used to explicitly associate form fields and their labels. This is covered under the WCAG Level A success criterion 1.3.1, 'Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.'
There are five primary types of form fields: text input, text area (usually larger than text input), radio buttons, checkboxes, and list boxes. The first two require only two tags: a <LABEL> tag with a FOR attribute and a <INPUT> tag with an ID attribute, e.g.:
<LABEL for='lunch'>Favorite Zingerman's sandwich:</LABEL>
<INPUT id='lunch' type='text'>
The value of the FOR and ID attributes should be identical; this creates the correct association.
Radio buttons and checkboxes require a <FIELDSET> tag to correctly group related buttons or boxes. They also require a <LEGEND> tag to provide a label that identifies the purpose of the array, e.g.,
<LEGEND>Choose your favorite pizza topping:</LEGEND>
<INPUT id='pa' type='radio'>
List boxes are handled differently from the other field types. They have a <SELECT> tag instead of an <INPUT> tag and use <OPTION> tags to identify the different options. For example:
<LABEL for='fball'>Choose your favorite player:</LABEL>
<OPTION value='1'>Denard Robinson</OPTION>
For more detail on correct form fields syntax, see Scott Williams' article on Best Practices: Forms and WebAIM's article on Creating Accessible Forms: Accessible Form Controls.
Coming up in our 3/8 issue: a Refresher on WCAG levels
What's entailed in captioning a video?
There are four basic steps to captioning:
For further information, visit the University's Web Accessibility website's captioning instructions page, the WGBH captioning FAQ, and the National Center for Accessible Media (NCAM) list of captioning tools and guidelines. You may also email email@example.com with your questions.
Coming up in our 3/8 issue: Complex tables
Background: There is no technical limit to how long the ALT attribute used to provide a text description can be; however, there is much disagreement over what the maximum length should be. My personal philosophy has become that ALT attributes should be no longer than 160 characters--the limit of a text message--because this forces web page authors to come up with succinct yet meaningful information.
However, there are some graphics for which 160 characters is far from sufficient. For example, bar graphics usually contain highly detailed information, all of which may be important to the reader. In this case, it's appropriate to provide a short ALT attribute (e.g., 'Bar graph of Michigan vs. Ohio State scores by year') and then point the user to a separate location that has a detailed description.
In the past, there has been a LONGDESC attribute for IMG tags. LONGDESC was intended to permit links to a longer description to be explicitly associated with the relevant graphics. However, LONGDESC is not supported in HTML5, and browser support is poor for earlier HTML versions.
The best current strategy is probably to put a link to the detailed description under or otherwise close to the relevant graphic (e.g., 'Click here for a detailed description of the bar graph'). The link may go to a location on the same page or a different page, as appropriate. The detailed description may be as long as necessary to communicate all important information.
This pie chart could be made accessible with an ALT attribute of 'Pie chart of U-M degrees granted in 2001' and with a link to a full description that begins, 'In 2001, a total of 178,101 degrees were granted: 22,350 in Education, 5,904 in the Visual and Performing Arts, 19,902 in the Humanities...' (etc.) Note that it is not necessary to describe any features of the pie chart itself, the instructions in the Legend, or anything except the actual data. (Scott Williams adds a side note that this pie chart example is not accessible to color blind folks, who are unlikely to access ALT attributes; designers should add cross-hatching or patterns where possible.)
This is a complex screen shot from a site that provides step-by-step instructions. It shouldn't be necessary to provide a detailed description; instead, simply provide an ALT attribute that clarifies the current instruction. So if the instruction were, 'Type the student's ID in the ID field,' the ALT attribute could read, 'Screen shot of Find an Existing Value page. ID field is the first text entry field on the page.'
In most cases, this could simply take an ALT attribute such as, 'Photo of University of Michigan President Mary Sue Coleman in cap and gown.' However, for a site where it is important to know the details of the gown, there should also be a link to a full description that begins, 'A sash across the top of the gown is in a dark velvet approximating Pantone Color 19-4057 (True Blue). The sash has a half-inch trim in satin approximating Pantone Color 15-1049 (Artisan's Gold). The sash is worn so it drapes...' (etc.)
For the photo above, describe an appropriate ALT attribute and the beginning of an appropriate full description (if necessary) for the following situations:
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:
With practice, it is possible to judge whether a color combination passes 1.4.3, or at least whether it needs to be verified using a free tool such as the Colour Contrast Analyzer.
(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.
3. Ratio=3.2:1 (Hint: The larger text is 20 pt.)
Automated checkers such as AChecker and WAVE may choke on pages with complex features. The following are some tips to make the process easier:
Have any other tips? Send them to firstname.lastname@example.org, and we'll include them in an upcoming issue.
Coming up in our 3/8 issue: Two ways to access AChecker
For the Accessible Apps team:
Pam Fons, Scott Williams, Jane Vincent