alt use cases

Folks -

I think we need to take a step back, look at the use cases for alt, and see
where we need to go from here. Right now, we're generating a lot of email on
the subject, but it does not seem like we're handling it like we need to be.
So far, after reading the zillions of messages on this subject, here are the
use cases I have identified. Please add others, since I have only skimmed
many of the emails and may have missed something:

1) alt is used to have words describe the image at a technical level; for
example: alt="image.jpg 200x320"

2) alt is used to have words describe the image at a descriptive level; for
example: alt="Picture of Bob and Jim at the big game"

3) alt is used to describe the consequences of some sort of user interaction
with the image (a tooltip): alt="Click the image to see it full size"

4) alt is used to provide a full transcript or summary of the text contained
within an image; for example, if the image is a full, scanned in page from a
document, the alt text would contain an executive summary, or the full text

5) alt is omitted or left blank under a wide variety of circumstances;
sometimes for good reasons (such as a purely decorative image being used as
a fancy box border, in which case alt text would not only be senseless, but
provide a distraction in the UI to the user) and sometimes for not good
reasons (the image is supported by one of the previous use cases, but the
user did not provide alt text for whatever reason)

We can divide our authors into a few major groups:

a) Users who do not realize or care that they are generating HTML, such as
people writing email in an HTML capable email client

b) Users who are aware that they are authoring HTML, but with little
technical know-how, like a blog author; these users will use many features
of their authoring tools, but are still 100% dependent upon those tools

c) Users who are writing HTML by hand, or sometimes using the "show source"
feature of their HTML software, but who have not read and/or memorized every
last detail of the spec (or maybe they learned HTML at version 3, and only
change what they know when it no longer works), and for whom conformance is
of little concern

d) Users who are writing HTML by hand, or sometimes using the "show source"
feature of their HTML software, and who *have* read the spec and remember it
well and refer to it when they are not sure about something; these users
read new HTML specs when they come out, and update their usage as
appropriate; conformance is a high priority for these users

e) Automated software that may or may not have a way to determine (and may
or may not have a good reason to not provide) appropriate alt text that
meets one of our use cases except perhaps CASE #5 (which can be considered
the "else" use case)

Finally, we can ask ourselves the following questions:

i) Is mandating accessibility a goal of the HTML 5 spec?

ii) Is it the HTML 5 spec's responsibility to ensure that as many people as
possible can consume an HTML document?

iii) Is it the HTML 5 spec's duty to force authors to only use images for
certain purposes?

iv) Would authors and tools be better served by having an alternative to
<img>, but used specifically in the event of CASE #5? Maybe, something like,


* Considering how much in-accessible functionality is already in HTML 5
(particularly with regards to support for AJAX-type work), it is clear that
this is *not* a goal. From the way the spec supports AJAX and multimedia, it
is clear the accessibility is a "nice idea" but certainly secondary to

* If this was purely about accessibility, we would be intent on insisting
that authors provide translations of their content in, say, the top 5 major
languages; that would force their content to reach a lot more people that
trying to make it play nicely with a screen reader.

* If we are going to mandate al text due to CASE #4, we should make the
<audio> and <video> tags (and anything that does the same in <object>) have
a mandatory @transcript system.

* It is impossible for any kind of software to validate CASE #1, CASE #2,
and CASE #3. Software that supports OCR could validate that the document
conforms for CASE #4.

* The proposals that I have seen that state that user agents, validation
tools, or authoring tools need to have some sort of built-in OCR system to
validate CASE #4... that is a major burden to put on tool authors.

* It is fairly clear to me that the use cases are too disparate to allow a
single attribute to handle them all, unless the attribute definition
provides zero usage guidance (let alone requirement on how to use) or
implementation details to authors and tool creators.

* I believe that having separate attributes and/or tags to handle each use
case will be a mess; as it is, @alt is frequently omitted when it should not


Received on Monday, 5 May 2008 14:10:53 UTC