TL;DR Yes. Yes, they are.
— MortenRandHendriksen (@mor10) March 24, 2015
For those who can’t see the embedded image, it’s quoting from the Mozilla developer documentation on the
Usage note: Omitting this attribute 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.
altattribute general guidelines: Section 188.8.131.52.2
When a Text Alternative is not available at the time of publication: 184.108.40.206.16
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:
- Within a system where it is impossible to add the text alternative.
- Displaying images that have been bulk uploaded using a methodology that extracted data directly from the images, without embedded alternative text.
- 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
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 220.127.116.11.21, 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