In the comments from my most recent article, “Supporting Standards that Support Accessibility,” a number of interesting thoughts were raised concerning the requirement (or lack thereof) of the alt attribute in HTML (HyperText Markup Language) 5.
It’s a difficult issue.
I’ve seen numerous articles around the web which discuss the fact that HTML 5 does not require the alt attribute. To some degree, this is true: HTML 5 provides exclusions to the requirement. In situations where an image is significant but no alternative text can be provided, HTML 5 recommends that the alt attribute be left off as an indicator that the image is significant (not a purely decorational image).
It’s actually quite a bit more complicated than that — the specification describes detailed guidelines for when the alt attribute should be left off, when it should be given a value, and when it should be provided without a value.
My complaint, and the complaint of many others involved in the web standards world is against the concept of providing any reason that the alt attribute may be left off. Ian Hickson states:
Empty alt text means the image is unimportant (decorative) and should be ignored. Missing alt text means that the image is important, critical even, but that there is no fallback text provided. The user agent is expected to treat the two cases differently.
At least, that’s what the HTML5 spec says at the moment.
I believe that it is important to provide a way to distinguish the two cases above; putting both of them into the empty alt=â€?” category would be, IMHO, bad for the accessibility of the aforementioned pages.
He’s right, of course — it is quite important to distinguish between insignificant images such as decorational graphics and between significant but undescribed or undescribable images. The challenge, then, is to come up with a solution to the problem which allows the alt attribute to remain.
So…what are some possible alternatives?
The first thing that comes to mind is to add a signifier attribute. Something which indicates whether an image is significant or non-significant. This would require some revision to HTML generating tools, but certainly no greater a change than that expected for new elements. It would be best to assume a default value when the element is not provided which assumes the image is significant, for backwards compatibility.
A second possibility would be to introduce a key term available to the alt attribute which would indicate significance. This strikes me as a bad idea, since it would have relatively poor backwards compatibility, and would require selecting a term which would become unavailable as normal alt text. Nah, that’s not really going to work.
Third…I’m struggling to come up with another idea…
I’m very open to any thoughts on the subject. Problems with these ideas are welcome, as are suggestions of any off-the-wall idea you may have!
Joe Dolson
Thanks, Mike!
Mike Cherim
None of that wasn’t lost on me, Joe. From this post or your recent one. I guess I’m just echoing your sentiments. To make my contribution here official, though, I will formally cast my vote for keeping the alt rules as are and expend any and all previously slated energies into further clarification of current usage to ensure the existing rules are implemented in such a way that supports best practices: standards, accessibility, and usability. I feel this strategy is what HTML (HyperText Markup Language) 5 should embrace.
Joe Dolson
Which may be the problem: a lack of understanding concerning what I’m discussing. Perhaps the realization that the HTML (HyperText Markup Language) 5 specification, as it exists today, currently does allow (and even require) the
altattribute to be excluded on certain types of significant images.There are two possible approaches to changing the HTML 5 specifications in this situation: fighting to remove that exclusion, so that we continue to use the existing standards (which I’m quite comfortable with), or attempting to come up with an alternate syntax which would allow the semantic situations described in the specification to be taken into consideration without requiring the
altattribute to be removed.I’m attempting to gather thoughts concerning these alternatives: there are many arguments on the web concerning fighting against the entire idea, but very little in the way of coming up with an alternative. (“Having our cake and eating it, too.”)
So am I — and that’s why this post, and conversation, exists: to attempt to find a new way of authoring the specification so that there is no longer a clause which allows the exclusion of the
altattribute.Mike Cherim
I wonder if this is indicative of a consensus of it not being, or perceived as not being, broken as is now. I mean I don’t think there’s any issue with the rules surrounding the tag’s usage, and I think it being used and left empty if the image has no significance is a good thing. That is like saying it is unimportant, ignore it. I’m afraid if the attribute become optional, a lot of people won’t use it and the situation will worsen.
Cool. I feel usage clarification is what’s needed most, not a change to the spec.
Joe Dolson
You know, an interesting thing about the comments on this post is that not one has actually had any alternate suggestion concerning eliminating the
altattribute in the specific case where a significant image does not have available or practicalalttext, as currently proposed in HTML (HyperText Markup Language) 5.Which, as it happens, was the point of the article.
I do value the discussions on the merit (and flaws) of the ideas I mentioned; but I was hoping to come up with something new, as well, rather than re-hashing the issue of “appropriate use of the
altattribute.”This suggests to me something rather significant concerning the sheer challenge of solving the problem, as defined previously.
@Mike – the HTML 5 spec actual describes very nearly exactly what you propose in some detail — it’s well specified, except that it includes one additional categories: images which are significant but which exist in a context where
alttext must be automatically generated and may not be provided by the author.It’s somewhat debatable whether it’s the responsibility of the syntax to come up with a solution to this problem, honestly, rather than the responsibility of an author, but in the clearly relevant world of user-generated content, it does seem meaningful to discuss the possibility of determining some alternative.
Mike Cherim
As you know Joe, based on my old article on this, I feel the secret to using the alt attribute correctly, to the most benefit that is, is to have a specific protocol for assessing the image. If it’s done right, the best choice can be made consistently.
This is how I defined it in the article, and I still think this holds true in my mind:
Regarding linked images: as far as I’m concerned they require alt text.
And as far as the alt attribute used to describe an image to the non-sighted: I have to disagree. I feel it’s much better to offer the alt attribute, and then leave it null (following the assessment criteria above). The vast majority of my embedded images are null. They’re using floated in some content and if they are to be described are done so in the text. This allows me to ensure the description in the right spot within the flow. Otherwise the alt text would sound out of place.
Now some people will state that ALL decorative images should be backgrounds put in by CSS (Cascading Style Sheets). I strongly disagree with this. First of all a decorative image may be part of specific content (like my blog post images). To do this, and to make the text wrap it, I’d have to float some HTML structure, then make an entry in my style sheet — for each post!
Joe Dolson
I figured it might be something like that.
As to joining the working group, I’ve already applied (following the comment from Ian Hickson on 12/25) – but haven’t heard back yet. I’m in the “You should get a reply back within about ten days, at which point you can fill in the Joining the HTML (HyperText Markup Language) Working Group form.” stage.
Geoffrey Sneddon
FWIW, I was taking what you meant as something like:
With such text in the spec, current generators’ output would be non-conforming.
Regardless, I’d invite you to take a more direct part in the work, you can find instructions on joining the effort here:
http://blog.whatwg.org/w3c-restarts-html-effort
Joe Dolson
I guess I don’t really agree with this: the signifier attribute should not be in any way relative to the
altattribute. Regardless of whether there is an attribute present which would indicate the significance of the image, the value of thealtattribute is semantically meaningful as an alternative text. Both attributes are relative to theimgelement, not to each other.Regardless, the method obviously has issues.
Geoffrey Sneddon
As you rightfully point out, all images are therefore significant. Omitting the attribute that denotes that @alt isn’t significant has a semantic meaning, and as a paraphrased before…
As your using @alt without @notsignificant, you aren’t using @alt for it’s appropriate semantic purpose, you fall foul of that must condition (which therefore means the document is non-conformant).
Joe Dolson
I consider it to be a limitation to keep in mind while I’m working on a project. It is an interesting semantic disagreement: ideally, the anchor element and the image element should be capable of successfully describing themselves independently: but it just doesn’t work that way.
Glad to help, though!
s1000
I’ll have to agree with you, especially when considering accessibility as an isolated interest, though in some cases (and they are few) it
willconflict with semantics, SEO etc.An image search on Google is (to my knowledge) based upon
altand file names, which could reveal some inconsistency.Anyways, thanks for enlightening me on the unfortunate reality of the
titleversus default settings in screen reader user agents.Joe Dolson
In theory, the
titleattribute of the anchor element should convey that information. However, in reality, screen reader user agents default to not readtitleattributes. Therefore, the lack of thealtattribute would mean that the only usable piece of information would be the URI (Uniform Resource Identifier). Although this may be useful in some contexts (http://www.domain.com/title-of-article.html) it may be extremely problematic in others, (such as http:/ /www.domain.com/default.aspx?doc_id=1234567890,ix0,9,4&lx=uga&dx=elx).Although the
titleattribute can be enabled in screen readers, the fact that it is not by default means that thealtattribute is the far more reliable means to provide link text information.In addition to that, in user-agents which do not support images or where images have been disabled, the
altattribute is used as a substitution for the image. Thetitleattribute is not used in this manner. Therefore, your suggested method would result in no image and no text. Most commonly, they’d be replaced by the URI of the missing image. Thetitleattribute would continue to be available, but it is not nearly as easily exposed to the user, since most user agents make relatively minimal use of it.It wouldn’t, if you never saw the image. In a context like that, you need to decide what the most important information to convey might be: if the image is unavailable, is it more important that somebody know what the image is of, or where the link points? My opinion is that the link trumps the image in every case. It’s unfortunate that the title attribute of the link doesn’t convey this information correctly, but that’s what we have to deal with at this time.
s1000
@Joe: In that case I’ll have to admit my perception of
altis somewhat skewed. Correct me if I’m wrong, but if an image is the link, it has to be enclosed by a link (unless of course it’s done with javascript, which I hope we can agree is highly unacceptable), which could contain all relevant info on the page it’s linking to (either by the URI (Uniform Resource Identifier) itself or a supplied title).Imagine an image of ‘Mona Lisa’ linking to a page about ‘Leonardo da Vinci’ – wouldn’t an
altsaying ‘Leonardo da Vinci’ cause some degree of confusion? To me it would.Joe Dolson
Unless, of course, the image is the link to the new page, in which case the
altattribute should be the name of the target page.(Just covering all our bases, here!)
🙂
s1000
@Joe: Well, I stand corrected on the precise definition on
alt😉I might have blured my point a little mixing in an image of a clown. My point was in fact that an
altshould not contain information about a specific font-types or a colors – that would as you point out be extraneous. On the other hand a navigational image of a clown could be enriched by a descriptivealtif relevant.Conclusion, better leave your
altempty, rather than an irrelevant page title that already should be obvious from your link URI (Uniform Resource Identifier)/title.Joe Dolson
No, I don’t think that’s true: this would not be a required attribute. If, as I proposed, HTML (HyperText Markup Language) 5 would assume a default value for the new attribute, then older generators would simply be flawed in that all images would be assumed to be significant.
I agree that this is a problem, but I don’t think it would create non-conformance.
Nonetheless, it’s an issue which needs to be kept in mind — older generators would, under this proposal, automatically generate code which could cause accessibility issues, since all images would be assumed to be significant.
The biggest problem is the fact that this method would require a combination of issues to be met in order to function correctly: the
altattribute must be blank, and the signifier attribute must be given a positive value. If the default is to always assume that the signifier is positive, then this idea creates major issues for accessibility:imgelements with blankaltattributes and no signifier element would require user agents to supply the missing information. Since this scenario actually describes most existing web documents, this seems like a very serious compatibility issue.Gotta think about this…
@Laura:
Thanks for those links! Akismet didn’t like them, but I appreciate them!
Geoffrey Sneddon
There’s a large difference here — any generator that creates HTML without the new elements will be just as conformant as it always has (provided it doesn’t rely on the small number of things that are no longer conformant — which are almost all things that aren’t used in the real world anyway); whereas if you don’t add this attribute it changes the semantics changing whether the document is conformant is not (as you must use elements/attributes/attribute values for their semantic meaning — if omitting an attribute changes the semantic meaning of another you have then lost conformance).
Needless to say, the current requirement (in the draft, so not really a requirement…) has serious backwards compatibility issues, namely that JAWS reads out the IRI of any |img| which does not have @alt (though this is already an open issue).
Joe Dolson
Perhaps “indescribable” was the wrong term to use. In this context, the purpose for the differentiation actually has very little to do with the webmaster, and far more to do with the user agent. Regardless of whether the webmaster has provided useful
alttext, the user-agent should have some means to determine whether it should skip the image or try to learn more information.This is why the empty
altvalue is critically important — rather than being bad practice, it provides crucial information to user agents to allow them to ignore the image. This makes a huge difference to the navigability of a document by a screen reader user.Steve Faulkner has done an extensive test on screen reader use of the
altattribute which you may want to take a look at.Ouch. No, that’s not true.
altis intended to describe the significant non-visual characteristics of an image: it is an alternate to the image, not a description of the image.alttext should be useful information when the image is unavailable.The best example for what you’ve described is to imagine the same page which images disabled: is it better to have
alttext which says “Circuses” or “Link to Circuses Page” (depending on context), or is it better to havealttext which says “Yellow/orange text with a clown in a wacky modified version of ‘Fontango’ reading ‘Circus'”?The second may be a very accurate description of the image, but it provides a large quantity of extraneous image to anybody actually trying to use the page.
s1000
@Gary: Regarding your example on navigation, the name of the page you’re linking to would already be (or should be) obvious from the link itself, hence the name wouldn’t make much sense –
altis meant for describing your image (if necessary), so unless it’s an image of a clown linking to the circus-page, the only description of relevance would be the specific font-type, colors ect.But then again, that is exactly what Joe defines as non-significant, isn’t it.
We can discuss if
altis proper implemented, but actually an emptyaltdoes add to accessibility by indicating that the image is in fact non-significant, whereas a missingaltcould ‘belong’ to an image of importance.Laura
I’ve put together a Wiki page on the subject of Omitting
altAttribute for Critical Content for the HTML5 Working group and a Request for PFWG WAI review. WAI’s Protocols and Formats Working Group (PFWG) official response should be forthcoming.Gary R. Hess
IMO there isn’t such a thing as “important but indescribable”. If an image is important, the webmaster must know what it is. I look at alt attributes more as a way to describe an image to a blind person than a way to describe the image to someone who already sees it.
Why would you put an image as navigation (which is bad, but for my argument humor me) and use an empty alt? Why not just put the name of the page instead?
As for backgrounds or non-important images an empty alt has been used, which doesn’t really make sense to me but to only validate. There just shouldn’t be an alt tag.
IMO there shouldn’t EVER be empty tags. There should be a clear description within the alt or no alt at all. An empty alt is just bad practice and makes no real accessibility improvement.