Artifact: pwWebSpeak

In the brief history of the World Wide Web, we have seen a number of technologies and ideas come and go.  The non-visual, or self-voicing, Web browser is one technology that emerged in 1995-1996 and sought to solve the challenges that people with visual impairments were facing when trying to access the Web. pwWebspeak was one such product, joined by IBM’s Home Page Reader, and a number of research oriented systems.  These products arose because screen readers of the time had significant challenges in presenting and interacting with Web content. Fortunately, with the advent of the W3C Web Accessibility Initiative and improvements in Web content, accessibility APIs, and screen readers,  these specialized browsers became largely obsolete.

Having faded into the sunset, the legacy of these pioneers is worth noting, as they served as a proving ground for Web accessibility and influenced how users of current screen readers interact with the Web today.

If you are interested in learning more about one of these pioneers, I have added an article on pwWebSpeak to the TakingInterfaces Artifacts section.

And, if you want to experience a self-voicing browser without stepping back into the 1990′s, Charles Chen’s FireVox add-on for Firefox is highly recommended.  For those on Linux, T.V. Raman’s emacspeaks, now in its 29th release, is still the best and just about only implementation of Aural CSS (Opera includes ACSS support).

Alt-erations

The section on the alt attribute in the current HTML5 working draft that begins with “What an img element represents depends on the src attribute and the alt attribute” really seems to miss the point.  This is the semantic Web era, correct?  Isn’t the conditional logic of the current draft really trying to affix a meaning or purpose to an image in all the wrong ways? Ambiguity is not the way.

I can just see the HTML5 alt attribute logic working so well in other contexts:

The Product Safety Agency announces a new toxicity labeling system.  All poisons are clearly labeled, except when they are not poisons, as indicated by a blank label. For products whose toxicity has yet to be determined, no label will be affixed.

Other applications of this logic come to mind, all equally frightening.

The very idea that alt be changed to a non-required attribute troubles me  much more than the complete departure of longdesc.  There have been ongoing discussions on this issue for some time, often heated, and WAI-PF is working on a response to the HTML WG.

Having been an early supporter and implementer of alt, I see only one real solution.

The role attribute is a key foundation in the WAI-ARIA efforts. Within ARIA, a role of presentation can be applied to an image,  indicating that the image is not part of the page structure and should be ignored by assistive technology.

Explicit indication of the authored intent of the image goes a long way toward reduction in ambiguity.  Rather than trying to infer the role of an image from the presence or absence of the alt attribute content, or of the attribute itself, role would explicitly define the authored intent of the image and its purpose in the interface.

I think, however, the current ARIA roles are insufficient (and yes, I will be responding to the request for comments on the Working Draft).

Following are two example cases of images with blank alternate text and the role attribute.

A purely decorative color bar:

<img src="colorbar.png" alt="" role="presentation" />

An image in a photo library, for which no alt text has been specified:

<img src="kif001293.jpg" alt="" role="content" />

I am not suggesting content as the ideal role for images which have a need for alternate text or description.  One could go off the deep-end and suggest photo, figure, map, etc. This needs to be simple, and content is a starting point, but not the end point.

Of course, we can still have an accessibility problem if alt is still left blank, but we won’t be guessing as to whether the image is decorative or the author just hasn’t gotten around to specifying the alternate content.

And as someone who once developed a non-visual browser, creating rules for dealing with alt (and its absence), and likely being among the first to implement longdesc support (for what it was worth),  having the ability to know that an image is really content is an important plus.  Further, knowing that an image defined as content happens to have a blank alt value could motivate the user agent and assistive technology to look for meaning where it can be found. ARIA’s describedby would be an obvious choice.

As an occasional optimist, I do have hope that technology will help mitigate the problematic assumption that content authors will neglect specifying alt (for a variety of sometimes understandable reasons). Authoring tools can become a bit more clever (or manipulative) in their approach to gleaning image alt text from authors.  And, embedded metadata, such as EXIF, may give us some clue about an image, where it was taken and when. It is not unlikely that we will see more useful metadata available, either in the image itself or queryable. And research is obviously looking for ways to solve the large photo library problem, and that can only help accessibility.

Keep alt required in HTML5, add role as a required attribute, encourage use of aria-describedby. Problem solved?