TL;DR Yes. Yes, they are.
Interesting on alt attribute. This is counter to what understood. Thoughts @joedolson? From https://t.co/sqRsvzQ32N pic.twitter.com/XZFplttADl
— 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 18.104.22.168.2
When a Text Alternative is not available at the time of publication: 22.214.171.124.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 126.96.36.199.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
DrupalArt; August 4, 2015 at 9:27 am
I love reading your blog 🙂 Very nicely written, very helpful content 🙂 Thanks a lot!
Philip Green; July 13, 2015 at 9:29 am
The sight of relief is that, a missing alt should not be represented as an error. While the description and the reason behind it is very handy, it certainly gives us an open window to experiment different methods.
Joe Dolson; April 10, 2015 at 11:24 am
Glad to hear it! Thanks for following up.
Ruth Maude; April 10, 2015 at 9:34 am
Hi Joe I just wanted to let you know I’ve found a plugin that offers the solution.With https://wordpress.org/plugins/frizzly/ you can set the pinit button to use the image description instead of the ALT text! Now to go through all my images and add descriptions. And thanks for helping me sort out the i button.
Joe Dolson; April 8, 2015 at 3:27 pm
Regarding the ‘i’ button – I’m guessing that you have WP Accessibility installed with the long description options enabled. This takes your media description field and uses it as a longdesc, so that description is available to users. It does this by generating a button to expose the value.
In any case, what you’d need to do in order to make use of the description field for a pinterest button would be to either cause it to render in the og:description field or in the description parameter of a pin it button; but I have no familiarity with any pinterest plug-ins, so I can’t really be specific on that.
Ruth Maude; April 8, 2015 at 2:11 pm
A Pinterest Rich pin will pull the og:description. That would be ideal – but then this would only work if the blogger has Open Graph enabled. See – http://learnwp.ca/wordpress-rich-pins/ & http://blog.tailwindapp.com/how-to-make-rich-article-pins/
I haven’t found a service that will do this. The Pinit button and social share plugins I’ve tested all use ALT.
The individual pinner could edit the description but it would be great if the Pinit button would pre-populate the pin description with the post meta description or the image description – something other than the ALT text.
I tried playing with the image description field. I found that the tools are still using the ALT text. I also found that the image description field no longer appears in WordPress after the initial insert into post screen. There doesn’t seem to be a way to go back and edit it. Also there is now an “i” button below my image . I don’t see this as a good option.
Joe Dolson; April 8, 2015 at 1:42 pm
Thanks for commenting, Ruth!
To start with – I’ll admit that I’m woefully ignorant about Pinterest. I know, however, that a pin-it button can send any description string as the description parameter of the Pin it button. I don’t know whether that string is what’s used for the alt attribute, however – do you happen to know that? If it is, then it would be fairly trivial to create a pin-it button that pulled an excerpt rather than an alt attribute – although I’m not sure that would solve the problem. If there are multiple images on a page, should they really all use the same description? In WordPress, images do have a ‘description’ field; what I’d suggest is that the ‘description’ field would be the ideal thing to pull.
Ruth Maude; April 8, 2015 at 9:24 am
Thanks for your accessibility plugin and for all you are doing to make the Web a more accessible place!
I have a concern. I’m getting to know Pinterest better. I see that most pin it buttons and sharing plugins use the image ALT text as the pin description. The problem with this is that it hijacks the ALT text from it’s original purpose. Bloggers will add ALT text but they will add long almost excerpt length descriptors.
Do you know of a WordPress plugin that will use an excerpt field or at least something other than the ALT text for pin descriptions?