The alt Attribute On img:Information Encoding And Markup Languages

1. Make alt optional.
2. Define additional role values for use with graphical elements including images.
3. Add new DOM method img.getEXIFData to pick out metadata from images generated from digital cameras.

Accessibility is a function of the willingness and ability of Web authors to provide the right level of content. Policy should focus on increasing willingness, whereas language design should focus on enhancing the ability to create accessible information. Conflating the two often leads to cases where it becomes impossible to detect if a piece of content is inaccessible because of lack of willingness or ability.

The img tag in HTML can carry a short alternative textual description as the value of the alt attribute:

 <img src="http://emacspeak.sf.net/emacspeak.jpg" alt="Emacspeak Logo">

The alt attribute was introduced in the earliest versions of HTML to allow for pages that included images to be rendered on text terminals. Over the years, it has been leveraged as an accessibility feature for helping blind users deal with pages that have images. The attribute has evolved into the primary poster child for accessibility — and in the process, we may well have lost sight of its failings.

HTML4 made the alt attribute required i.e., documents with missing alt on img tags were considered to be in error. The design sketched here is put forth with the goal of making things better — both with respect to encoding the maximal amount of information about an image, while ensuring that instances where such information is not available are easily detectable.

With attribute alt required, a conforming img tag can be in one of the following states:

1. Carry an alt attribute that describes the image.
2. Carry an alt attribute that is meaningless or otherwise unrelated to the image (a common spam technique in the early days of the Web).
3. Carry an alt attribute that is the empty string "" --- this idiom has been used to indicate that an image is purely decorative.

In the above, (1) and (2) are not readily distinguishable. Spam checkers can detect abuse of attribute alt. However, it is impossible to detect that the provided description does not match the image, or that an attribute value of "" for an image is inappropriate because that image is not purely decorative.

Also, as demonstrated by the example of the Emacspeak Logo above, authors even when well-intentioned are split on what to place in the value of the alt attribute when it's the single place they have for attaching metadata (for purposes of this discussion, I'll ignore the rarely if ever used longdesc property. Thus, an author could correctly ask if the alt attribute for the above example ought to have been any one (or perhaps all) of:

• A yelow Labrador saying "Emacspeak — the complete audio desktop!".
• Raman's guide-dog, Hubbell Labrador saying "Emacspeak — The Complete Audio Desktop!".

See discussion about the role attribute later in this document for a solution.

Viewed from a purely information encoding point of view, making attribute alt not required gives us one additional bit --- cases where the image description is not provided can drop the alt attribute altogether — rather than cloaking such cases by providing an empty string as the alt value.

Making alt optional in the manner described might appear to be a backward step from an accessibility perspective given that that attribute was required in HTML4. However, if making the attribute optional helps us distinguish cases where the information is missing, this is a win.

In addition to instances where an author chooses to ignore accessibility altogether, there are practical usage scenarios where such alt text is missing:

1. Photo sharing sites, e.g., my own photo gallery at Picasa Gallery For Raman. Incidentally I upload pictures here, and at the time of upload dont know what each picture has — I then have friends and family annotate the pictures with meaningful comments. Notice that the resulting descriptions are far richer than any alt text that I might have been able to provide.
2. Street maps.
3. Satellite imagery.
4. Street view images.

Given that ARIA is now being implemented in browsers, and that as a consequence, attribute role defined by that specification is integrated into HTML, I believe we have an excellent opportunity to improve the situation with respect to photo-sharing sites and other automatically generated digital imagery. We can extend the legal values accepted by attribute role with a small number of well-known values, e.g.:

1. role = 'photo'
2. role ='logo'
3. role ='drawing'
4. role = 'satellite image'

I believe the right set of such values should be specified within the WAI-PF group and rolled into the HTML specification based on implementation experience. This will enable adaptive technologies produce the right form of feedback going forward.

This might also be a good time to expose one additional DOM method on element img given that :

• The majority of the photos uploaded to the Web are from digital cameras.
• Digital cameras produce EXIF metadata automatically.

It would be advantageous to add a img.getEXIFData() method that returns a JSON dictionary containing the EXIF data found at the value of attribute src. I believe such a DOM method would be extremely useful for mainstream applications, and is consequently likely to be implemented in the browsers. Such a method would be a major win for accessibility over the current status-quo of attempting to stuff all image metadata into a single attribute.

The img.getEXIFData() combined with meaningful role values on img elements would make the accessibility situation with respect to images significantly better than what it is today.