TL;DR Yes. Yes, they are.

For those who can’t see the embedded image, it’s quoting from the Mozilla developer documentation on the img element:

Usage note: Omitting this attribute [alt] indicates that the image is a key part of the content, but no textual equivalent is available. Setting this attribute to the empty string indicates that this image is not a key part of the content; non-visual browsers may omit it from rendering.

Almost any accessibility consultant will tell you that the alt attribute is always required. Every image should always have an alt attribute – whether it’s empty or has text, it must be present.

But the HTML5 specifications appear to have an exception to that. What is this exception, and why? The HTML5 specifications describing the alt attribute are quite extensive. What do they say on this?

I’ve written on the topic a couple of times myself, so it’s not exactly a new topic to me, either.

Except where otherwise specified, the alt attribute must be specified and its value must not be empty; the value must be an appropriate functional replacement for the image. The specific requirements for the alt attribute content depend on the image’s function in the page, as described in the following sections.

Source: alt attribute general guidelines: Section

When a Text Alternative is not available at the time of publication:

This isn’t readily quotable, and I recommend reading these guidelines yourself, but these are the special cases where alt is supposed to be omitted entirely, and it’s very specific.

Specificity is fabulous, of course – but what does it mean? The examples given describe circumstances where the images have been uploaded in bulk, and the only data was extracted from the image file name; situations where the site does not provide users with the ability to add a text alternative; or in the case of an interface designed to allow a user to enter alt attributes for a set of images not yet described.

These are reasonable circumstances. They are also extremely specific circumstances. So, while there is truth to the information from Mozilla’s developer network, it’s equally important to recognize that the usage case for this should be very carefully considered. The cases in which it’s allowable to omit an alt attribute are:

  1. Within a system where it is impossible to add the text alternative.
  2. Displaying images that have been bulk uploaded using a methodology that extracted data directly from the images, without embedded alternative text.
  3. Displaying images in an interface designed to add alternative text for the images.

If you’re authoring content, and inserting images into that content, you are not in one of those situations. In fact, in any case where you are specifically choosing an image to use, you are (by definition) in a situation where the alt attribute is required.

If you’re allowing images to be automatically moved from your phone to Flickr, then that’s a bulk update scenario where no opportunity to add the alt attribute exists. So it’s reasonable that a site like Flickr, which displays a massive volume of images, could legitimately omit the alt attribute unless the user has come in and added it.

So why do accessibility consultants say it’s always required?

Because there’s almost no chance that you’re working in one of the rare environments where it actually isn’t required. If you’re actually creating a web site (as opposed to a web service or a administrative tool), it becomes vanishingly unlikely. And from a testing standpoint, it’s far more valuable for testing tools to continue to report that the alt attribute is required.

Because it is.

For what it’s worth, the HTML5 specifications actually provide a specific attribute for use in the circumstance where they have been unable to obtain a text alternative and have omitted the alt attribute. It’s <sarcasm>concise, and easy to remember<sarcasm>: generator-unable-to-provide-required-alt. Of course, it’s only for use by generating tools, so you shouldn’t have to remember it. (From, Guidance for Markup Generators)

Having omitted the alt attribute, what can I expect?

Good question. The web is riddled with alternative text mistakes – alt attributes on elements that don’t support them, missing alt attributes where they’re required, etc. Should a conformance checker ever accept a blank alt? How should a screen reader deal with this? Do we assume that some of these cases fundamentally require sighted involvement?

The HTML5 specifications do provide some guidance. First, a missing alt should not be reported as an error if the img element is in a figure element with a figcaption that contains content which is not whitespace and the figure element has no other text node descendants. (Whoof. That’s a mouthful.) Second, a missing alt is acceptable if the img element has a generator-unable-to-provide-required-alt attribute with an empty string value.

I’d far rather that the situation required an alt attribute in all cases, and allowed for an attribute that indicated that the alt attribute was automatically generated, and may not be trustworthy, or something to that effect. To me, that would be more elegant. But this is what we have, and what we need to live with.

I’d love to see some data on the number of compliant alt omitting implementations. I can’t help but suspect it would be lower than the usage numbers for longdesc.