Speaking ALT Text
“An educated consumer is our best customer.” So says the advertising slogan for an East Coast clothier (U.S.). It’s difficult to argue with that concept.
As designers and developers we are technology consumers. We pursue a great deal of education. How good is it? An earlier quiz tells us that when it comes to knowing how screen readers actually behave, many of us depend on others. We depend on hearsay. Hmmmm… Hearsay is often considered unreliable, and is simply inadmissible in a court of law. Although I am certain it is unintentional, there’s a fair bit of poor information published about what screen readers actually do. Some of it is based on older technology, some on legends passed down from antiquity (very old tutorials), and a lot on hearsay.
Wouldn’t it be better to have first hand experience? I can hear you all nodding agreement. I can also hear protesting the high cost of screen readers. Few of us can afford to keep a stable of screen readers that are used only for testing.
OK. I can help a bit. I have a few late model screen readers and I also have simple audio recording tools. I’ll use them to get you closer to what these screen readers actually say. I’ll start a collection of recordings so you can hear for yourself what these tools say.
My collection of screen readers include:
- Freedom Scientific’s Jaws, version 6.1
- GW Micro’s Window Eyes, version 5.0
- IBM’s Home Page Reader, version 3.04
All of these tools are currently optimized to work best with Internet Explorer 6.0. So, that is the browser I am using for the recordings. Except where noted, I am using these tools with their default settings. They can be tailored with an ever increasing number of settings, but I am not expert enough to mess with those.
The first topic is simple, ALT text on non-essential images. There are many recommendations. For a very long time the W3C has been advising all images have some sort of ALT text. Some people report that the absence of ALT text causes the image path and file name information to be spoken. Some people advise null text: alt=”". Others think at least one space is needed: alt=” “. And of course there are those who label spacer images with: alt=”spacer”, or bullets with alt=”bullet”. <sigh>
The good news is that all choices except the last work very well in the latest screen readers. The tools have, as Joe Clark yearns, grown a few brain cells … but not many. All three of the tools I listed cope very well with the complete absence of ALT text. One has to go in and change default settings to force them to read the path and file names. By default, they are silent when ALT information is missing. Equally satisfying, they don’t care whether the ALT text is only a pair of quotes or a single space.
I used this test case as the basis for the following recordings:
- Speaking ALT text with JAWS 6.1 (164 kb mp3)
- Speaking ALT text with IBM HPR 3.04 (191 kb mp3)
- Speaking ALT text with Window Eyes 5.0 (186 kb mp3)
From these actual examples, and giving some consideration to older tools, the single Best Practice for ALT text on non-essential images is: alt=”".
Should you want to contribute similar recordings to the collection, send mail to bob at this site’s domain address.
May 15th, 2005 at 7:36 pm
This is a great service to be able to hear these test cases read this way. Very enlightening for someone who does not own the software, but wants to explain to people the best way to code the alt attribute for nonessential images. I hope you will continue this practice with other test cases on other topics.
May 16th, 2005 at 2:50 am
“Some people report that the absence of ALT text causes the image path and file name information to be spoken.”
Hmm…
It is in JAWS 6.10 actually - if you use the image as a link graphic!
But that, on the other hand, probably disqualifies it as a “non-essential image” ;)
May 17th, 2005 at 6:58 am
hello,
its great that some of us study the accessibility problems on sites :) . I’m writing my own blog about accesibility, especially for people with some kind of special vision problem or totally blind people. Hope you visit my blog and test by yourself the accesibility i have reached on it.
Continue making this work forever master. Regards from Spain. Mc
May 17th, 2005 at 5:21 pm
First off, thanks for doing this. This is good stuff. Learning about and working with screen reader output has been, perhaps, been the most difficult part of accommodating those accessibility needs on the web.
I have taking my pages and running them through Opera’s Voice option. It may not be a screen reader per se, but I do feel it has been a enlightning experience none the less.
On the hosting site I recently made, I tried a couple of new things. First, the site is http://gbhxonline.com. Specifically the two things worth noting.
1) On the “Home” page there is an image in the first paragraph. This image has text on it which conveys information (inline with the text before and after) and prompts the site vistor to click for more. The alt attribute in this case closely matches the text in the image. With images off, I see the alt text so it seems to work well that way, and using the Opera Voice option, I discovered it seems to read well too.
2) On the “Hosting” page I have the hosting plan details in lists. These individual lists are marked by a small icon on each. The icon bears the plan identifier (i.e., Gold Plan). The text following the icon says the reveals the plan identifier so having the alt attribute read “Gold Plan” would have been redundant. I could have left the value null, but instead I tried something new. I made the alt attriubte a bullet, not the word, but an actual bullet (•). By voice it says bullet, a demarcation so I think I’m okay with it. Without images you get the bullet itself. I like the way it turned out.
May 18th, 2005 at 2:09 pm
These examples are extremely helpful. Thank you so much!
May 18th, 2005 at 6:16 pm
Sorry to double post but I wanted to add that the Opera Voice option reads exactly as the other do.