Image alt Attributes Not Always Required in HTML5
It has long been accepted that the
alt attribute of the
<img> element, while not a perfect method to provide a text alternative to an image, is still a necessary attribute to provide at least some level of access to the image content for users who cannot see the image (whether by disability or otherwise).
alt attribute is required on images in HTML 4.01. The notion that the
alt is a de facto required attribute in future versions of HTML is echoed in the WCAG version 1.0 and 2.0 (7.1 of WCAG 1.0, H67 and F38 of WCAG 2.0). It is even stated as much in the latest W3C HTML5 working draft document, HTML5: Techniques for providing useful text alternatives, as you can see in this sample conformance item:
When an image is decorative and it is the authors intent that it not convey any information, an empty alt attribute SHOULD be considered as an indication that the image can be safely ignored.
The W3C uses the strongest language in its arsenal when it says an
alt should be used, even in this example of an empty attribute.
Yesterday the W3C mailing list rendered a decision on Issue-31 and Issue-80 (a combined issue). This issue was last reported by Ian Hickson of WHATWG on the W3C mailing list. Confusing though that may be, it’s still a decision on the W3C list. The issue summary (not the decision):
Require that authors include alternative text for images. Provide detailed instructions and examples for doing so to all readers of the HTML specification.
The decision as outlined on the mailing list:
- The presence of aria-labelledby does not make missing alt conforming.
- The presence of role=presentation does not make missing alt conforming.
- The presence of <meta name=generator> makes missing alt conforming.
- Use of private communications does not, in itself, make missing alt conforming.
- The presence of title makes missing alt conforming.
- The presence of figcaption makes missing alt conforming.
Essentially, if you use a
title attribute on your image, or wrap it in a
<figure> with an associated
<figcaption>, then you may exclude the
alt attribute. In addition, the presence of a
<meta name=generator> element, which implies the HTML was generated by some sort of WYSIWYG editor or automated tool, also makes the absence of an
alt attribute valid.
There are arguments on both side of the issue, and the decision handed down on the mailing list does a good job of collecting them, even if the qualification of each may be cause for dissent. Given that the W3C is pushing HTML5 to Last Call status next month, it’s unlikely this will change.
alt attribute is intended to describe the image to which it is affixed, but the (redundant)
title attribute has been implemented by authors to provide more value to users owing to browsers typically rendering it as a tool-tip. While this doesn’t preclude an author from inserting an
alt as well, it also may result in use of solely the
title when it may not offer a sufficient description of the image.
The argument for excluding
alt in the presence of a
<figure> and associated
<figcaption> element applies best when the browser supports those elements. In time they will, but given the collection of users still on IE6, older assistive technologies, and the lack of understanding of these new elements, this leaves a gap for some users. This isn’t a clean transition with a guarantee of the same level of accessibility as outlined in the current HTML 4.01 specification and accompanying WCAG versions.
I do not agree with letting an HTML page off the hook simply because it has been generated by an automatic tool of some sort (relying on the
<meta name=generator> block of code). This is really included to allow generated HTML5 to validate, not because the tools are incapable of inserting a blank attribute value (though they may not have been coded to do so). The argument against this references the current lack of support for ATAG guidelines within HTML editors and generators. I think this caters to ego by allowing authors to claim validation that would otherwise fail.
In the end, I think the best approach (at least for web developers and authors) is to still require it in all cases, reducing the need for seasoned web developers to retrain themselves. Ideally, these web developers would still continue to include
alt attributes in all cases. Developers of HTML editors/generators (who care about the output) will hopefully follow suit instead of inserting additional complexity at the risk of misunderstanding (and mis-coding) these new rules. Makers of HTML editors/generators that cannot implement the spec should not be given a free pass.
If you’re really interested in
<img> attributes on the chopping block, read up on the fun regarding
longdesc at longdesc in HTML5.
Update: April 27, 2011
Steve Faulkner, member of W3C HTML Working Group along with other W3C working groups, provides a more in-depth and detailed overview, including a re-hash of the full decision in his post HTML5 Accessibility Chops: the alt decision.
Update: May 2, 2011
I wrote more: More on Image alt Requirement in HTML5
Update: June 11, 2012
I wrote yet more: Image alt Exception Change Re-Re-Requested
Update: November 24, 2013
I wrote even more: Image alt Exception Change Re-Re-Re-Requested
"The W3C uses the strongest language in its arsenal when it says an alt should be used, even in this example of an empty attribute."
Actually, the strongest language in the W3C's arsenal is MUST as found in various parts of WCAG.
That being said, you hit the nail on the head. This decision, and all decisions regarding accessibility features in HTML5, is strictly motivated by validation with the least effort possible.
W3C follows RFC 2119, which defines "must", "should" and "may", among others.
Yes, they really did write a standard for that.
Thanks for setting me straight. After more than a decade reading W3C specs, I was somehow convinced they didn't make absolute statements.
Wow. Good for them for making a standard.
Standards are for sizzies.
[…] Not including an alt tag is not valid HTML5, except in some situations like when using <figure> with an associated <figcaption>. You can read more about it here. […]