Here is a brief write-up on the use of alt on the HTML img tag. This is being written based on my personal experience of the Web, as well as from watching the Web evolve since its inception. I have used most of the available screenreaders on the market, though for my own work, I use Emacspeak --- The Complete Audio Desktop. Note that the design presented here is based on technical metrics such as the ability to encode information effectively — and is in no way aimed at defining or determining accessibility policy or conformance criteria. In my experience, mixing these has detremental effects on both the language design as well as the policies used to ensure accessibility.
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:
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:
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:
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.:
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 :
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.
Date: <2008-08-26 Tue>
HTML generated by org-mode 6.06b in emacs 23