Access Matters

Chris Heilmann gives us 10 Reasons Clients Don’t Care About Accessibility. Read it over at Digitial Web Magazine.

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.

Speaking of labels on form controls, Patrick Lauke brought up an interesting question. The spec for labels says “More than one LABEL may be associated with the same control by creating multiple references via the for attribute.” There are all sorts of questions that come to mind. First of course is simply “Why?” Then, what would it look like? Are all labels displayed? For screen readers, what does it sound like? Are all labels spoken? In what sequence?

Tell us why you might use multiple labels and what you think will happen.

In the mean time, I’ve created a contrived test case that offers one possibility. It will be very interesting to see what it does in various browsers and screen readers. Please try the test case and let us know what happens.

Part 2…

In part 1 we hid form labels using display:none and found that some screen readers treat display:none on form labels differently than they treat display:none on other elements. Sigh…

Intent on hiding the form labels (again I disagree with the premise) another technique uses the title attribute on the form control and does not use any label element at all.

We have already learned that the default verbosity settings in some screen readers keeps them from speaking title attributes. The user has to turn them on, if they ever learn the setting exists. However, it seems some screen readers automatically speak titles for form labels. Another inconsistency?

Our test case has two select controls, each holding a hidden label in their title attributes. For comparison purposes, the test case also has an image with the image description in both the ALT attribute and title attribute. Which titles are spoken? (Test case updated to add both alt and title text 9/4/2005)

As always, please try the test case in as many screen readers as possible and let us know what you hear.

Handling form labels has been on one of my back burners for a long time. This week, both Shannon and Becky found an anomaly based on a suggestion in the WCAG 2.0 CSS guide, item 5.5. There, it shows several examples of coding form labels which are hidden from visual display.

Actually, I think a well done design shouldn’t have to hide labels, but that’s for a different quiz. One of the examples uses display:none. As we know from many tests here, display:none hides material from screen readers as well as from the visual display. Well, hold on to your hats boys and girls. Some current screen readers do speak labels that are hidden with display:none. Gheesh, how inconsistent can we get?

OK. Let’s try a label test case and see what we get. Try it in as many screen readers as you can, and try it in different reading modes. If the screen reader has a forms reading mode, does it behave differently than straight through reading mode?

Sept 1 update - I have updated the test case to include a paragaph that is also treated with display:none. This let’s us more easily see if screen readers ignore some hidden elements but not others.

JavaScript is flourishing everywhere. AJAX is the latest new thing on the web, bringing us a wave of dynamic applications for getting things done. 37 Signals brought us Basecamp and Backpack. Other applications, like Next Action are popping up daily. How well does today’s assistive technology cope with these delightful new applications?

About two months ago, both Mike Stenhouse and James Edwards suggested we do some JavaScript testing here. Then, a few weeks later Derek Featherstone wrote a very interesting article suggesting that people using assistive technology might fare better with JavaScript disabled. At about the time the WaSP was forming the Accessibility Task Force, the four of us agreed to collaborate on testing the accessibility facets of JavaScript with today’s assistive technology.

First, some short introductions: (alphabetic by last name to avoid any favoritism)

• James Edwards - the man behind the [brothercake] web development consultancy. James lives somewhere in what he calls a rural area of Shropshire, UK.
• Derek Featherstone - operates the furtherAhead web development firm and the WATS.ca accessibility consultancy, and lives near Ottawa. We know him as a member of the recently formed WaSP Accessibility Task Force.
• Mike Stenhouse - a freelance web developer living and working in London.

We will attempt to find out what screen readers actually do with various JavaScript events by using a series of test cases which break things down to small test areas. This first case focuses on navigation among links. It handles a range of different keyboard, mouse and UI events, and creates a log of every event that’s recorded, so that we can determine which events are generated by different devices. If a screen reader discovers an event and passes it through it will be logged as normal. If the screen reader does something different, that too will be logged (we hope). At the bottom of the test case, a simple form mails the log back to us where we’ll puzzle over the results.

Don’t worry, we are not collecting anything to do with your identity.

By the way, there are no questions with this quiz, as we don’t yet know the right questions to ask. This one is all about quizzing not you, but the technology. Comments are indeed welcome about behaviors you see or hear as you run the test case.

Thanks in advance for trying the test case in as many assistive technology devices as you can.