Access Matters

The previous quiz question asked about supplementing ALT text with TITLE text, and how it might affect assistive technology. As always, we find variations in how assistive technology handles the various combinations. I’ll leave the recap for later. Now, we’ll turn to a more comprehensive question and test case about TITLE text. As Joe Clark rightly pointed out, the previous test case was too simple. OK, Let’s try a more complete test. TITLE text can be applied to almost any HTML element, so that’s what I’ve done.

The Titles Everywhere test case has TITLE text applied to every element. I’ve used almost all the elements, even those which are containers for others. A TITLE on an UL? What good is that? I don’t know, but the specs allow it. It’s interesting to see what appears on hover for each of these, and it might be interesting to see what assistive technology does with them. Try the test case and report any interesting findings.

Since every quiz needs a question…

Q. For what elements do you normally use TITLE text?

• A usually only images
• B images and … itemize

A few months ago we looked at a test case which presented the various ways of providing text alternatives to an image using ALT text. Modern assistive technology handles most methods well. Even in cases where the ALT text was completely missing, assistive technology remained silent. Older screen readers would annoyingly read out the path names of images without ALT text. They’ve learned not to do that.

The current best practice for a purely decorative image, an image that adds no material value to those listening to the page with assistive technology, ALT coded as two quotes with no intervening space: alt=”".

Of course, we all know that the current best practice for an image that conveys information is ALT text that accurately describes the image. That is exactly why ALT exists.

Now, what about those developers who want to use TITLE text instead of, or in addition to, ALT text? ALT was designed for and is the best practice method for providing a text alternative to an image. Yet, some are drawn to use TITLE text because of the visual hover effect (incorrectly) produced by a certain widely used browser. Oh yeah, it looks nice, but what does it do for those who listen to the page rather than see it? Do they get to hear only the ALT text, only the TITLE text, or both … more than they might want or need?

I’ve created a test case which includes various combinations of ALT and TITLE text. You can try it with your favorite assistive technology. You can also tell us why you prefer a particular method.

Q. For images which convey information and require a text alternative, I prefer method: ____. Please explain why.

• A using ALT text alone
• B using ALT text and TITLE text
• C using TITLE text alone

Our first tests in this area explored navigating links which have JavaScript actions. Now, we turn to navigating forms which have actions attached to the various form elements. Our goal is to understand how browsers and screen readers react to script actions.

The test case asks you to simply navigate straight through one form and then interact as much as possible with a second form. The test case is self-documenting, recording results in a textarea which gets sent off for our analysis.

After we collect a good spread of results, we’ll publish them.

Please try the test case in as many browser and screen reader combinations as possible.

Four of us got together several weeks ago to try to determine how JavaScript affects screen readers and other assistive technology. Our first test was in Quiz 4.1.4: JavaScript - part 1. This joint (ad)venture included James Edwards, Mike Stenhouse, Derek Featherstone and myself. James created the core of the first test case by launching actions from links and then cleverly recording results in a form at the bottom of the test case page. It took a couple of weeks to amass a credible set of test runs and about that much more time to assemble the results. James wins the prize for persistence and determination by plowing through the results and putting them in displayable form. I’m still scratching my head about what they mean. They don’t yet translate directly into best practices.

The results don’t fit easily on a standard blog entry, so I have posted them on a page better able to display the tables. Go see the full explanation and results, and tell us what they mean to you.

This fine announcement is showing up all over the place. On Juicy Studio, on WaSP, on WebGraphics, and most importantly on the new site itself. Go visit the Web Accessibility Tool Consortium. Steve Faulkner, Gez Lemon, Makoto Ueki, and Mike Paciello have some very nice tools planned for us.

A colleague from the CSS-Discuss mail list, Zoe Gillenwater suggested a variant of “offleft.” This one uses a large negative left margin. Let’s try it. Please try SR Test 9a on every screen reader and browser you have.