Access Matters

Contents:

• Label hiding technique #1
• Label hiding technique #2
• Multiple labels
• Legend and fieldset
• Best practices

Some time ago, Joe Clark suggested “This, however, is a topic that should also be tested and written about.“

This series has its roots in WCAG 2.0 Guideline 4.2, Success Criteria #4, which states:

The label of each user interface control that accepts input from the user can be programmatically determined and is explicitly associated with the control. [I]

Note that “[I]” (invisible) indicates that a criterion does not specify how content should be presented. Apparently, that gave the green light to some WCAG contributors to find a way to hide labels whether it makes sense to do so or not. This led to the first two quizzes in this series.

Label hiding technique #1

The first quiz used an example from the CSS Techniques for WCAG 2.0. In that example, two techniques are described. My interest was drawn to the display:none technique. In earlier tests, we found that when display:none was used on other elements (headings, paragraphs, etc.) the screen reader usually did not speak those elements. Results from the 5.2.13 test case shows that some screen readers do indeed speak labels that are marked display:none. By the way, this still appears to be an open issue for the CSS Techniques document. The screen reader implementations demonstrate a level of inconsistency that I find absolutely confounding. Treating the attribute one way for some content and another for different content is beyond any standard, or any sense of logic. What happens when the day arrives that screen readers actually become standards compliant? If we have built sites based on these inconsistencies, it will be our problems to resolve. This is clearly not a best practice

By the way, a second technique recommended in that same W3C example suggested using nosize. As James Edwards from Brothercake reminded me in the comments, the nosize technique also fails in one of the current leading screen readers, Window Eyes 5.0. So, it too is Not a best practice.

Label hiding technique #2

The second quiz looked at another technique suggested in some rather old email correspondence about that same article. An alternative proposal was to not use the form label at all, but to add a title attribute to the form control. OK, sigh, we tested that idea too. The results were a bit more consistent. Screen readers will generally use the title text if it is available, especially in forms reading mode. My complaint with this technique is that it completely bypasses using the correct structural element, the label. In short, it is not compliant with yet another WCAG guideline (4.1) which advises using technology correctly. Not a best practice.

Multiple labels

Then, along comes Patrick Lauke who wonders about how well multiple labels work. I asked “Why have multiple labels?” Owen Rodda proposed using multiple labels for handling errors during forms validation. Use the first label as the regular label for the field, and a second as an error notification, if needed. Once again, we find surprises. A couple of the screen readers merrily speak all the labels we might want to assign to a field. Jaws, however is inconsistent (again). Of three different reading modes tested, two modes speak only the last label of a set of four. In the other reading mode, Jaws speaks the first label of a set of four. Two thirds of the time Jaws might speak what you want, but three thirds of the time it’s wrong if you wanted multiple labels spoken! If you are going to use this technique, constrain yourself to no more than two labels. That will get you to probability 0.66 with Jaws.

Legend and fieldset

OK. Let’s move along. This next one should be very straightforward and simple. We have a tool for grouping like items together, fieldset. We can then use legend within fieldset to provide information about the group of fields contained within the fieldset. Looking back on the first test case for this series, we had a simple text paragraph and two controls. The better implementation of that example uses a fieldset to wrap around the two controls, a legend to replace that text paragraph, and proper labels to keep the controls from being ambiguous. Take a look at the new fieldset and legend test case to see the difference. Try it in screen readers if you please. Even without testing it extensively, I expect it to behave very well in screen readers, and exactly as we expect. Styling? That’s a different question, with an answer coming up next.

Best practices

The best practices are simple. Use the structural elements we’ve been given. Legends and labels are structural elements; highly recommended. Title attributes are very poor substitutes. The only reason to use them is as redundant information in the hopes that older screen readers will speak them. However, don’t depend on titles alone. Group like items together with a fieldset and then use the fieldset’s legend to add supplemental instruction for that group of controls. Use real labels on every control to insure their meaning is obvious. Just because the legend says, “update month and year,” we shouldn’t assume the first control is actually the month. Label it! Avoid hiding labels. Any innovative designer should be able to create a form that uses legends and labels with no need to hide either, and the W3C should ditch their example of hiding labels.

If there is no other choice than to hide labels, use the techniques we know work universally well: offtop and offleft. Do not use display:none; It is unreliable and inconsistently implemented in screen readers. Do not use nosize as it fails in the latest version of a popular screen reader. You can also check other techniques that we have previously tested.

Now, let’s add some style. Cameron Adams, the “Man in Blue” has already done a very fine article on Accessible, stylish form layout. He builds on the original article with a set of form templates which show you six different ways to layout a form. Very nice work indeed.

Lastly, try the fieldset and legend test case in screen readers and let us know what you hear. It might also be fun to point your screen readers at Cameron’s form templates.

This entry was posted on Saturday, September 10th, 2005 at 2:13 pm and is filed under Test cases, Principle 4: Robust, Articles. You can follow responses to this entry through the RSS 2.0 feed. You can leave a response or trackback from your site.