Aaron Doust and I have been working on an experiment in access to photographs contained in Web pages.
There are three issues at stake:
Four Web pages at Aaron’s site have been developed to show how, in the real world, this problem can be solved. We are bringing accessibility out of the realm of the theoretical here.
First of all, every image on Aaron’s site (not just the test pages in question) now has an alt text, which is required in HTML 4.0 and has always been recommended in previous versions of HTML. A great many Web authors fail to include the dead-simple feature of alt texts, which by themselves make a site easier to use for people in the three categories above.
There is, however, a new technique for making visually-complex pages accessible to anyone who can’t see the graphics: Writing descriptions of the images where alt texts are insufficient. Typically the descriptions are linked via a small but noticeable D. tag alongside the image or in a navigation bar. The downside of this technique is the visibility of the D. links – and, of course, the difficulty of persuading Web-jockeys that the 30 seconds it takes to write the description is even worth it in the first place.
The photos contained in these four subpages now have written descriptions. (They’re Aaron’s photos and he wrote the HTML; I wrote the descriptions.) The photos depict various biketrials riders in Perth, Australia. Bicycle trials is a discipline of cycling in which the aim is to ride over, across, and through obstacles without putting your foot down. If the topic isn’t of much interest to you, well, make allowances. The point here is that even a hobbyist page can be accessible, and if hobbyist pages can be, corporate Web sites easily can be accessible, too.
There are four pages with four different approaches.
longdesctag for long descriptions.
Other techniques we could have used, but did not, include setting up a neighbouring single-pixel GIF the same height as the image that is itself a link to the long description. This is an unsatisfactory solution for various reasons. If you’re using a graphical browser with graphics turned off, your font size is quite unlikely to be small enough to display the (D) or D. so that you can actually click the thing. If you have graphics loading turned on, you never see the link, and might notice it only if you catch the status line changing as you happen to move the mouse over it. This technique tends to render you more blind than you already are. Solely in text-only browsers does this approach provide accessibility and elegance.
We did not write descriptions of the entire pages as a visual whole, and all the images are presented within tables, which are certainly not universally accessible.
We sent out word of our experiment to relevant mailing lists. The instructions:
What we want you to do is to break our pages. Load the four subpages in every conceivable combination of platform, browser, graphics mode, and assistive technology. The more unlikely, the better. We especially want to hear from PDA users (like Newtons or PalmPilots) and people using speech output. Tell us how the pages look and how easy or difficult they are for you to navigate and interpret. Every aspect is up for discussion, from coding to appearance to writing. All suggestions articulated in a reasonably good-natured tone will be considered, and we may update the pages over time to try new things.
From Petr Fuchs: If you look at that picture page on high-res screen, (D) tags interfere with the right border of table where picture is placed. If you insert a <br> tag in front of the (D) definition string it will always fall on the bottom of the picture and be centered.
I viewed with graphics activated on another occasion, and the wallpaper on the right side is distracting [and reduces] readability of the text; get rid of it or make it light-coloured, or use frames to move the text to the right of that wallpaper column (as on my page). If you intend to have your page more readable by people with low vision, blast description text with big bold fonts without any background (descriptions are shorter and could fit on-screen in a bigger font since descriptions are a standalone page).
Case 1: Suggestion – leave the picture inlined on the caption page as well. After all, it is not that useful to be told that the related file’s name is derekbbqlog.jpg. But seeing the picture while reading the caption.... Supposing that images are turned off anyway, or that the picture is already in the browser’s cache, this should not be a big bandwidth issue.
I was going to make a comment about Lynx’s options for handling images with or without alt strings, but having had a closer look at your source, I was wrong. Currently I get either:
Derek Price hopping from the BBQ ring to a fallen log.
= link to large image
Derek Price hopping from the BBQ ring to a fallen log.-[IMAGE]
= link to large image
= link to small image
What I’d like:
Derek Price hopping from the BBQ ring to a fallen log.-[INLINE]
= link to large image
= link to small image
but this is rather a limitation/design choice of Lynx. Must give some more thought to what really does not please me. Just the chosen word, perhaps?
Case 2: Ooops, true: no
available, but knowing people, Lynx may become the first browser to
support it :-) The regular repetition of "Big Picture" is a bit
Case 3: Here again you might miss the picture when reading the description. Now, there would be definitely no sense in putting them all on the description page this time. Thumbnails, perhaps? That would leave you with three sizes of pictures. Not ideal either. Though thumbnails with ALT="Back to photos" could replace that link?
Case 4: Same comment as Case 1: include the picture? Are you displaying the description in a separate browser window, though? In that case it’s another issue. Anyway, one thing I don’t like either is having my workspace filled up with browser windows.
Back to your pages: a comment concerning all of them is that the small inlined captions on the main pages are closer to the following image than to the related images (when rendered by Lynx, at least). This is a bit confusing. Oh, yes: and avoid if at all possible the phrase "Click on the image"/"Click here to...." On a hardcopy, this becomes a bit surrealistic :-), but my main point is that I don’t click. Perhaps "select" is more neutral (though just as surrealistic, I agree).
From Philip Webb:
Case 1: You need to mark the captions "Caption:" since alt text and captions come out as links with nothing to differentiate them.
Case 2: This is a mess. Each title is repeated (underlined the second time), with a link called "Big Picture" in-between each pair.
Case 3: This works quite well. Only one page to download if you just want words; however, there’s still the nuisance that each caption is repeated.
Brad and René sound like a right pair of nerds ... (grin).
Browser support for
longdesc is poor but
longdesc, “but it’s some[what] hidden,” says Alexander Clauss. “Control-Click on the image and choose in the contextual menu ’Image/description’ and iCab will open a new window and display the description in it.”
longdesc. Right-click or Control-click on the image, and select Properties. A link to the description, if any, is presented there.
longdesc. Neither does Opera or Lynx.
So just at the level of browser readiness, we have a problem.
longdesc may not be ready for prime time.
We don’t think the four approaches can be vastly improved. They all have pluses and minuses. In the future, we may use this information to lobby the World Wide Web Consortium for updated HTML specifications.