The case of the missing alt attribute.

Jennifer Sutton brought this interesting factoid to my attention today: the single most common HTML validation error is the missing alt attribute.

Of the 100 most common validation errors collected by W3C Love, a missing alt attribute comes it at number one — with almost double the occurrences of the next most common error.

It’s 2012, and the key mistakes in HTML seem to remain the same.

Now, one can’t help but hope — since these are the results of validation tests — that these numbers also reflect a large number of people who went “Oh! Whoops! Better get that information in there.” Of course, some of those people may have then gone on to write in “Spacer.gif. 600 bytes. White line.” as their alt attribute.

Obviously, this raw number of errors doesn’t demonstrate a lot of definitive information. However, the mere fact that this is literally the most common validation the error points to some serious problems in HTML education or in HTML generating tools.

I can understand people providing bad text alternatives. When you read over the guidelines for authoring alt attributes — either in the HTML 5 specs or Steve Faulkner’s slightly-more-easily-understood Techniques for useful text alternatives, it’s easy to get overwhelmed. The chains of instructions: this MUST be done, that MAY be done, this is REQUIRED, that is OPTIONAL…it can be a lot to digest.

But omitting the alt attribute entirely is kind of scary. Yes, it’s true that the HTML5 spec currently (and unfortunately) allows the alt attribute to be excluded in certain very limited situations — but the statement that alt attribute is optional in HTML 5 is far from accurate. It is definitely still required, and omitting the attribute is discouraged in no uncertain terms, as below:

Such cases are to be kept to an absolute minimum. If there is even the slightest possibility of the author having the ability to provide real alternative text, then it would not be acceptable to omit the alt attribute.

Even the most casual search of phrases like “alt attribute optional” brings up many, many results clearly indicating the importance of using the alt attribute without even a suggestion that the attribute is in fact optional, so it seems like somebody would have to work pretty hard to come away with the impression that it was optional.

Why is it left out so frequently?

We need better education. Ignorance is still the primary guiding factor in casual web development. When people are exercising barely-learned skills, they tend to go in the direction of the simplest possible set of instructions — leaving out any portion which doesn’t seem to have any impact. That means that images are included with a src attribute; possibly with width and height; and frequently with some kind of inline style or border instruction. Alt attribute? Why?

Any time you read up on an alt attribute, you’re likely to run smack into the TL;DR problem: explaining how to use alt attributes in any detail means a long, involved explanation. Even explaining the incredible difference between an empty alt attribute and an ommitted alt attribute is over the head of many layman content authors.

We need better decision making tools. It’s necessary to simplify. The experts need to work out the complex details of what, why, how, and when an alt attribute should be one thing or another. For the layman, it needs to be summed up as simply as possible.

Here’s my idea of a generalized alt attribute decision tree:

  • Is this image a link or form control?
    • Yes: Alt attribute must communicate the destination of the link or action taken
    • No: Continue on!
  • Does this image contain text?
    • Yes: Alt attribute should include the communicative text of the image (not text included for visual effect)
    • No: Continue on!
  • Does the image contribute meaning to the current page or context?
    • Yes, and it’s a simple graphic or photograph: the alt attribute should briefly describe the image in a way that conveys that meaning.
    • Yes, and it’s a graph or complex piece of information: the information contained in the image must be included elsewhere on the page.
    • No: the alt attribute should be empty.
  • Is the image something other than the above?
    • The alt attribute should be empty.

This very definitely does not cover all cases. But it’s much better than nothing; I hope that somebody is able to make use of it. If you have a quarrel with the wording or instructions, let me know in the comments!

It is incredibly hard to resist covering more and more issues here. But the purpose of this decision tree is to provide a simple and understandable tool to navigate the most common circumstances. This is not the place to explain the entire scope of alternative content.

Have something to contribute?

« Read my Comment Policy

13 Comments to “The case of the missing alt attribute.”

  1. I think the decision tree should have, in big bold type just before the list, that it is not acceptable to have the alt attribute missing. It should explain if the developer is ever in a situation where he thinks that’s what he should be doing, then putting alt=”” is definitely the preferred path to take.

    That seems to be the main confusion, that developers think an empty alt attribute is equivalent to an omitted alt attribute.

  2. Hi Jeanne, thanks, have tweaked the decision tree.

  3. Steve,

    The HTML5 alt text decision tree is a big improvement. It also addresses the more complex cases in a clear and direct manner. I recommend putting the option “Yes, but a suitable alt text is unknown …” last of the 3 YES options. The other two options (photo or graph) are common and easy to understand. “suitable alt text is unknown” – is that referring to a photo site use case?

  4. Thanks for adding that, Steve! I think it will (hopefully) make the process of understanding alt attributes that much more straightforward.

  5. Hi Joe!
    have added a simple alt text decision tree to the HTML5 alt text spec: based on your decision tree. thanks! feedback welcome.

  6. Hi Joe,

    take a look at the ‘developer version’ it has (i hope) a more user friendly style (and shorter line length).

  7. Thanks for all your comments! For the record, Steve, I find your techniques document fairly easy to follow – but I also recognize that it will pose some challenges for the layman, simply because the concepts are not obvious unless you’re steeped in accessibility already.

    I think that a decision tree is a valuable tool as a quick reference – they are straightforward to write in text, and also can be displayed effectively in a visual format, for those who will benefit from it. Obviously, the grossly simplified version above isn’t one you’d want for an official techniques document.

    The understandability issue is really one which is inherent to the structure of W3C documents, honestly. I think that it’s a problem with needing to wade through 2-3 screens of official notices and documentation before you even arrive at the meat of the document. I think that the writing itself is perfectly readable; but there are a lot of issues to be dealt with before the visitor even gets the opportunity to work through that aspect.

    There are design issues, as well – mostly relating to line length, which act to give the impression that this document will be difficult to read. (Of course, these issues are largely out of your control.)

  8. Hi Joe,
    you wrote:
    “Steve Faulkner’s slightly-more-easily-understood Techniques for useful text alternatives”
    I have thought about adding a decision tree. It s a work in progress and I would appreciate ANY feedback on how to make it more understandable.

  9. @paul,

    Generally by default screen readers will ignore images without alt attributes unless the image is the child of a link. Details of how JAWS handles images

  10. The hardest choices for me, are when including an alt title for a logo – when to describe it, when to identify it just as the brand’s logo, whether or not to also include a link title if it’s linked….

  11. How are alt attributes handled by screenreaders?
    I heard a rumor that when a screenreader encounters and image without an alt, it reads out the full URL of the image source. Is that true?

Return to Top