alt attributeNow everyone and their goldfish has talked about the HTML5 draft allowing you to omit alt under certain conditions I’d like to rehash it a bit more. I made an image viewer for myself which allows people to browse through photo gallaries and view specific photos, such as the one of the building the W3C in Boston is based in. I am currently following HTML5 (omitting alt) as it wasn’t really clear to me what would be a better solution given the single constrain I have: not finding it necessary to provide replacement text for all those images. This would take too much time for little benefit. Let alone the fact that I wouldn’t even know how to adequately provide replacement text for those pictures that would still make the application enjoyable. Hopefully photo recognization software improves soon.
There is another way of looking at this problem: what is the easiest way to make your application conform to HTML? In HTML4 this would be specifying alt="". As you may realize, this would be worse than omitting alt as it tells the user agent that the image means nothing. Nothing at all. As far as the user agent is concerned there is not even an image there. Yet this is probably a solution people will pick because they are forced to make their pages conform. This does not seem to help people who need to know something about the critical content, but can not view it for whatever reason (blind, driving, et cetera).
Unfortunately, screen readers deal rather badly with images that do not specify alt. Those images are either completely ignored or image analyzing, which makes you cry, is performed. At some point this issue needs to be solved and I’m willing to bet that it will not be on the producers’ side.
There is more though, one reason that was mentioned for not letting alt be omitted is that this is already frequently practiced for images that likely not have any meaning whatsoever. I’m not sure if there is any data on this, though. However, it is also unclear how much images there are that have alt specified with a useless value. After all, those two are equally bad, not?
One potential solution to reduce the noise of images where alt is omitted, but should not have been omitted because the replacement text is the empty string, is to do some simple image analyzing. You could check the size, whether the image solely consists of transparent pixels or consists of pixels that are all the same color, et cetera. I suspect that a solution that tries to deal with the legacy web as well will have to be something in that direction, unless more research shows that it is not a realistic approach.
Just a small problem: you spelled "provide" as "provive".
What I've come to realize is that pictures that appear inline with the text usually needs alt text to make sense when the picture isn't showed. Pictures that act as block-level elements usuallly doesn't, though. Perhaps these two use-cases are different enough to make a case for a new element to describe the latter, no-alt, picture? Just thinking out loud here.
Either way, I agree with you on the cases where alt can (and should) be omitted. <img /> is not the same as <img alt="" />. And I still (as I've always done) think that the whole idea of injecting alternative content into attributes is a seriously flawed idea.
Perhaps I'm missing something here, but I have to say I disagree. The alt attribute doesn't specify an image's "meaning" it specifies alternate text in place of the image.
Anne,
There is a critical flaw in your reasoning - the fact that *you* cannot see a reason to include some alternative text, and that one of the 'justifications' was that it would "...take too much time for little benefit". Benefit to whom? You? Or a blind user?
When I visit the link you provide to "the building", [http://anne.is.weggeweest.nl/image-viewer#2006,boston,9] there is ABSOLUTELY NOTHING THERE that would be of any use to a non-sighted user (outside of the fact that the title is "Boston [Image viewer]): no explanatory text on screen, no alternative text for the image, no long description - essentially nothing if I cannot see. Heck, I can see and still have zero information about this photo. The really sad thing is, with even minimal alt text, a blind user potentially could Google the image of this fanciful building and use the photo in a different way - say perhaps a research project on humor and architecture? Think outside of the box!
When it comes to the "option" of adding ALT text, this has been what I have argued from the beginning - by making the attribute an author based decision creates a scenario where authors can (and most likely will) start finding "justifications" based on their opinions, rather than facts and needs. Already we have seen (directly and indirectly) that many of the HTML5 draft authors are at times unclear or unaware of some of the subtle nuances behind accessibility considerations. We have absolutely nothing to indicate that, given that these intelligent and informed content authors are oft unclear, that the "mainstream" authors who will be taking this new standard will be any better or wiser in making these determinations. This then will open the door to a backward slide - the Pandora's box I have referenced so often.
Anne, while you may not find it necessary to add alternative text here, you are not dependent on them (it?), thus your motivations for adding or not adding are skewed by your personal perception and reality. This is a personal site, and so it is your option to neglect or shutout some, many or all potential visitors by your choices and actions. (Why you would want to do that is a whole other issue, one that transcends any technical discussion), but if you choose this path, what real difference is there between alt="" and nothing? You've still caused the damage/harm to the end user who needs more than just the photo. However, by insisting that images have an alt value, you, as content contributor must constantly tell your authoring tool, "No, I do not want to add alternative text", as opposed to deciding from the onset that the effort cannot be justified by the end results, so I'll just not bother; because Anne, that is what you have just said:
... it wasn't really clear to me what would be a better solution given the single constrain I have: not finding it necessary to provide replacement text for all those images. This would take too much time for little benefit. (emphasis mine)
(and Anne, it's ALTERNATIVE text, not replacement text. The text does not seek to replace anything, but rather to provide an alternative when the image cannot be seen - subtle to be sure, but also goes to the heart of the matter).
John, I’m not sure what your point is, but you’re not being realistic. Providing accurate replacement text for about six hundred images is a pain. That’s the point. This is even more true for the millions if not billions of photos on photosharing sites that people upload from their phones or cameras during trips around the world and what not. As I said in the article, it is unrealistic to expect content producers to solve this problem. It is more realistic to expect technology to solve it.
Jonthan - you are spot on with those few words!
To make ALT optional would add a particular semantical meaning to it that it doesn't currently have – and which it would be backward for it to have.
Anne,
My point is that images should *always* have an alternative descriptor of some sort or other (even if it is the worst of all: alt=""). Authoring tools, "mandated" by a spec to always include alternative text with images, will "bother" content contributors each and every time, asking for alternative text (heck WYSIWYG authoring tools should not continue - the "submit button" should be grayed out until a value is provided). If you want to avoid adding good text, fine, but I want to make it difficult for you to avoid. That's "social engineering", as opposed to mechanical (technical) engineering.
Will uninformed or lazy authors still use null values (alt="") - of course they will. But the authoring tool will always "remind" them that they could/should do better. By establishing this context, then all that is needed is education. The option of *not* providing usable alternative text still remains, but that's a social issue, not a mechanical one. However user agents should be smart enough to have multiple ways of digesting and handling a simple text string of alt="".
Time and time again, it's not always the code/spec that has it wrong, oft times it is the authoring tools and the lack of education. There is no need to throw the baby out with the bathwater!
You suggest that it is more realistic to expect technology to solve this problem. What is the proposed technology solution then? Until we can see this better way, the spec is entrenching (condoning and permitting) the ability to create inaccessible content. I am willing to assess this technology solution with an open mind, but asking us to take it on the word of the draft editors that such a solution will emerge is unrealistic. If we are to accept that supposition, then surely you too can accept that LONGDESC can eventually emerge as a viable solution. If I am to believe you without proof, then you should believe me without proof.
You speak of "accurate" alternative text (please, it is not replacement text - be accurate when you describe what we are discussing) - but I'm not completely sure where this requirement comes from - one of "accuracy". While ideally an accurate alternative text for every image is the ideal, there is certainly a case to be made that for users that are dependent on alternative text, even less accurate alternative text is better than *no* alternative text. Based upon the feedback I have received from actual blind users, shades of gray are permissible here.
The largest fear however is if the spec emerges that suggests that it's OK to "sometimes" not provide alternative text, that the "sometimes" will become open to interpretation, misuse and abuse (despite best intentions). The HTML5 spec says:
"In certain rare cases, the image is simply a critical part of the content, and there might even be no alternative text available...In such cases, the alt attribute may be omitted."
However what you said was that you did not find "...it necessary to provide replacement text for all those images. This would take too much time for little benefit." AND ANNE, THAT RIGHT THERE IS EXACTLY THE WHOLE POINT! It became a subjective decision, based on your opinion, rather than any pure-play technical reason. Technically you *could* add alternative text to your slide show images, you just personally felt that it would take too long for little benefit. (and I note not zero benefit, but little benefit)
What I am having the hardest time understanding however is *why* the HTML5 authors feel this (the option to have no alternative text) is important. How can anyone justify it's benefit to accessibility? I'm not arguing that alt="" is right, but no alternative text at all is even "wronger", and using scenarios such as Flickr, Photobucket and your image viewer only illustrate the flaws in those tools - it still does not justify the fact that those images *should* have some usable alternative text.
How can a group that wants to dismiss LONGDESC because it is flawed at the same time condone authoring tools that are flawed and seek to write a SPEC to forgive those flaws? This will never be solved exclusively by technology, there will always need to be human intervention in the creation of alternative text (*especially* if you want it to be accurate too) - believing otherwise is IMHO naive.
What I am having the hardest time understanding however is *why* the HTML5 authors feel this (the option to have no alternative text) is important. How can anyone justify it's benefit to accessibility? I'm not arguing that alt="" is right, but no alternative text at all is even "wronger", and using scenarios such as Flickr, Photobucket and your image viewer only illustrate the flaws in those tools - it still does not justify the fact that those images *should* have some usable alternative text.
Two things:
It is assumed that bad server-generated alt text is worse than UA-generated alt. At least the UA developers can reasonably be expected to put more thought into it than server-side developers. If you are a screen reader developer, it is an issue for 100% of your customers. If you are a photo sharing site developer, chances are your customers are asking other kinds of features to get attention instead. (The situation with current JAWS does not match this assumption, but so far it has not been explained if we should expect this situation to continue with JAWS in the future.)
The empty string as the alt text is reserved to mean that the image should be suppressed in aural rendering. If this meaning is honored by the UA, the UA does not have an opportunity to generate a better placeholder for images whose presence should not really be hidden.
I’m not arguing that alt="" is right, but no alternative text at all is even “wronger”
No. The meaning of alt="" is “this image is irrelevant in non-visual contexts”. If you put it on images that are relevant in non-visual contexts, you are lying – plain and simple. You are purposefully preventing visitors from knowing anything about the image in non-visual contexts.
It’s better to let people be lazy but truthful, than force them to be deceitful about their laziness. Neither option is great, but making them lie just makes things worse.
1. It is assumed that bad server-generated alt text is worse than UA-generated alt. At least the UA developers can reasonably be expected to put more thought into it than server-side developers. If you are a screen reader developer, it is an issue for 100% of your customers. If you are a photo sharing site developer, chances are your customers are asking other kinds of features to get attention instead. (The situation with current JAWS does not match this assumption, but so far it has not been explained if we should expect this situation to continue with JAWS in the future.)
How is the UA going to generate alt text? I keep hearing of this miracle, but nobody has explained how this is going to work. And forgive my naiveté but is not HTML supposed to be agnostic? How "JAWS" deals with web content should not matter a whit - not everyone uses JAWS (any more than everyone uses Internet Explorer). Finally, screen readers are *not* user agents in the same way that Firefox or Safari are user-agents. They are adaptive technology tools that interact with user-agents and other software. Continuing to pretend otherwise does everyone a dis-service.
So how will a User Agent such as Opera or Firefox provide usable alternative text when the author has not provided 1 stick of a clue as to what the image is? This is all a wonderful theory, but we need to see this in practice.
2. The empty string as the alt text is reserved to mean that the image should be suppressed in aural rendering. If this meaning is honored by the UA, the UA does not have an opportunity to generate a better placeholder for images whose presence should not really be hidden.
And what placeholder will the UA be generating? I keep hearing half of a solution here. If an image's presence should not be hidden, then the content author should be making it's presence known. Henri, you cannot suck and blow at the same time - either the author does it right, or the author does it wrong - presuming that the User AGent will "fix it in the mix" is ludicrous. I cannot see how omitting an alt value (even if it is null) improves anything, and given current situations it specifically causes a poorer user-experience, as by default the Adaptive Technology "heuristically" seeks to provide *something*, which is often the file name: "image: DC24356 dot jay-peg".
How is the UA going to generate alt text? I keep hearing of this miracle, but nobody has explained how this is going to work.
How is the server going to generate alt text? I keep hearing of this miracle, but nobody has explained how this is going to work.
[Hint: “authors should write alternative content” has not worked for over a decade and there is no sign that it will change in the next decade, or ever.]
I cannot see how omitting an alt value (even if it is null) improves anything
So how does providing a null alt value on all images improve anything?
(What useful information does it add? I know it does add some useless information (in fact, it’s a lie), which you refuse to acknowledge, but anyway.)
The phrase «a null alt value» demonstrates how it is even difficult find a way to talk about the difference between noALT and ALT=""! Which again proves another thing: For authors, the choice noALT versus ALT="" is not a simplification – but a complication.
Lacking authoring tools and time etc may lead to invalid HTML. But it is then we need to have realistic advices about working alt texts. On a photo site, perhaps the word «photo» or «photo 1», «photo 2» etc could be enogh – sometimes the best. It could even be that alt="" would be the right thing – if everything is described in the context – and the image doesn't function as a link. Because, when used as a link, the ALT text acts as link text – which, again, is a common image usage not mentioned in the HTML5 draft – and a very typical scenario on photo sites.
(What useful information does it add? I know it does add some useless information (in fact, it’s a lie), which you refuse to acknowledge, but anyway.)
You are so obsessed with the «meaning» etc, that you fail ot see the functional roles of ALT texts. You also talk as if the «meaning» of ALT="" is given. But there are several reasons for using ALT="". The lie would be to present a page – which doens't work for your readers. Then you have fooled them.
The irony is that the supporters of the noALT option seemingly have unrealistic views about what constitutes a useful alt text. Such as when Henri Sivonen talk about bad server-generated ALT-texts. You run the risk of letting the perfect solution become the good thing's enemy. And while repearing lacking alt text is a must, there are, to my knowledge, no UAs that write «IMAGE» in some context, and «Photo» in other contexts, «Illustration» in other contexts etc. Also, blind users should be able to communicate with seeing users - and varying alt texts according to what the UA see fit certainly doesn't help that.
1. It is assumed that bad server-generated alt text is worse than UA-generated alt. At least the UA developers can reasonably be expected to put more thought into it than server-side developers. If you are a screen reader developer, it is an issue for 100% of your customers. If you are a photo sharing site developer, chances are your customers are asking other kinds of features to get attention instead. (The situation with current JAWS does not match this assumption, but so far it has not been explained if we should expect this situation to continue with JAWS in the future.)
How is the UA going to generate alt text? I keep hearing of this miracle, but nobody has explained how this is going to work.
(I should have said that UAs can generate a placeholder rather than alt text.) You probably aren’t going to get anything even remotely like human-authored alternative text until UAs are AI-complete. Chances are, though, that images could coarsely be classified by software as large photos, thumbnails, icons, etc., which at least gives some context even if it doesn’t tell what’s in the picture. I expect even that to be better than reading out some numeric file name. Even reading mere “image” without any classification would be better than reading out numeric file names!
And forgive my naiveté but is not HTML supposed to be agnostic?
Agnostic of what? You seem to be saying it should be opinionated about alt.
How "JAWS" deals with web content should not matter a whit - not everyone uses JAWS (any more than everyone uses Internet Explorer).
I see a different sentiment later in your comment.
Finally, screen readers are *not* user agents in the same way that Firefox or Safari are user-agents. They are adaptive technology tools that interact with user-agents and other software. Continuing to pretend otherwise does everyone a dis-service.
From the point of view of the content provider, that’s an implementation detail at the other end of the pipe.
So how will a User Agent such as Opera or Firefox provide usable alternative text when the author has not provided 1 stick of a clue as to what the image is? This is all a wonderful theory, but we need to see this in practice.
In general, when you want to tease usefulness out of an uncooperative data source, you try to recognize patterns using probabilistic methods. A piece of software can guess whether an image is a photo, thumbnail or icon by looking at the dimensions of the image, for example.
2. The empty string as the alt text is reserved to mean that the image should be suppressed in aural rendering. If this meaning is honored by the UA, the UA does not have an opportunity to generate a better placeholder for images whose presence should not really be hidden.
And what placeholder will the UA be generating?
Saying “image” would be the simplest placeholder. That’s what VoiceOver does with Safari. The next step would be saying “photo” or “icon” depending on the characteristics of the image.
I keep hearing half of a solution here. If an image's presence should not be hidden, then the content author should be making it's presence known.
Exactly! You seem to be conflating mere making the presence known with providing a proper textual alternative.
Henri, you cannot suck and blow at the same time - either the author does it right, or the author does it wrong - presuming that the User AGent will "fix it in the mix" is ludicrous.
That attitude ignores the shades in between. Like not doing the right of writing a textual alternative but avoiding doing the wrong of polluting the place reserved for alternative text with something like a file name generated by a camera.
I cannot see how omitting an alt value (even if it is null) improves anything,
It could give you something that’s more useful than silence or “DC24356 dot jay-peg”.
and given current situations it specifically causes a poorer user-experience, as by default the Adaptive Technology "heuristically" seeks to provide *something*, which is often the file name: "image: DC24356 dot jay-peg".
That looks like an appeal to the current behavior of certain products mattering more than a whit.
We appear to have a different view of what is permanent badness and what is transient badness. I consider the unavailability of alternative text in some cases permanent badness from the point of view of unattended markup generators. I view the behavior of screen readers reading out numeric file names as transient badness. That is, a bug that can be fixed in a handful of products eventually.
You seem to be viewing the state of AT usability bugs as permanent badness and considering the unavailability of alternative text as transient badness that could be fixed by somehow forcing people to write alternative text.
On a photo site, perhaps the word «photo» or «photo 1», «photo 2» etc could be enogh – sometimes the best.
Indeed, people seem to have a very different idea of what is being advocated. I wonder if John Foliot was asking for the word “photo” and a number for Anne’s gallery.
there are, to my knowledge, no UAs that write «IMAGE» in some context, and «Photo» in other contexts, «Illustration» in other contexts etc.
But is that permanent badness or transient badness? Why?
Also, blind users should be able to communicate with seeing users - and varying alt texts according to what the UA see fit certainly doesn't help that.
I don’t understand what you mean here. Surely a human-provided alt text is even more varying.
You seem to be viewing the state of AT usability bugs as permanent badness and considering the unavailability of alternative text as transient badness that could be fixed by somehow forcing people to write alternative text.
I would suggest that JF explain how his mythical authoring tool is to solicit alt text from a user uploading photos from his cell phone. Even in the cases where it's technically possible to force the user to enter alt text, as when Anne is batch uploading 600 photos from his home computer to his photo sharing account, any user interface that forces Anne to enter 600 alt texts (or even one that forces him to hit RETURN 600 times), before it will consent to upload his photos, is going to fail dismally in the marketplace.
heck WYSIWYG authoring tools should not continue - the "submit button" should be grayed out until a value is provided). If you want to avoid adding good text, fine, but I want to make it difficult for you to avoid. That's "social engineering", as opposed to mechanical (technical) engineering.
But it's crappy social engineering. A good Authoring Tool will make it easy for Anne to do the right thing. It won't force him to do something stupid, like hit RETURN 600 times.
Jacques, just because we can upload images from a cell phone does not mean that we should. It's the same as scanning pages in a brochure and uploading them as content for Web pages.
Jacques, you're into MathML - right? What if someone said that it's too hard to write MathML on a cell phone. It's better to write out a math formula on paper and use the built-in cell phone camera to take a snapshot of the formula and upload it as a graphic. Would you be happy with that? Or if they say dump MathML altogether because it's easier to use images of math formulas.
Jacques, just because we can upload images from a cell phone does not mean that we should.
There's an old adage, "Don't spit into the wind."
Saying that people shouldn't post photos from their cell phones, or blog from their cell phones or whatever is a paradigmatic example of spitting into the wind. Be my guest, if that's the sort of masochism you're into.
What if someone said that it's too hard to write MathML on a cell phone.
It's too hard to write MathML period. What I'd like to be able to do is read MathML on a cell phone.
Or if they say dump MathML altogether because it's easier to use images of math formulas.
I hate to break it to you, buddy, but that's what the overwhelming majority of people do. Nobody uses MathML, because doing so is too hard. Nearly everyone uses images of their equations (or punts, and posts a PDF file). Telling then that they are wrong, and that they should use MathML instead, is another example of spitting into the wind.
If you want people to "do the right thing," you have to make it easy for them to do so. In the case of MathML, that's what I've tried to do. I may or may not succeed, but at least my efforts aren't a manifest waste of time.
Jacques, just because we can upload images from a cell phone does not mean that we should.
Yes, “stop the world” is a proven approach. Ask the RIAA, MPAA or the newspapers about it.
You are so obsessed with the «meaning» etc, that you fail ot see the functional roles of
ALTtexts. You also talk as if the «meaning» ofALT=""is given.
Obsessed? What are you talking about? The functional role of alternative text is very simple: in non-visual contexts or if the image cannot be displayed, the alternative text is to be used instead. What is there to fail to see?
And so the meaning of alt="" is given by that very definition. Given the functional role of alt, using alt="" clearly means “in non-visual contexts or if the image cannot be displayed, nothing should be used instead”.
There is nothing complicated here.
But there are several reasons for using
ALT="". The lie would be to present a page – which doens't work for your readers.
Yes, if you use alt="" for relevant images, and then your page doesn’t work for your readers. Exactly. And yes, people will use alt="" for several different reasons if you force them to always insert alt, and the user agent cannot distinguish them.
There are, to my knowledge, no UAs that write «IMAGE» in some context, and «Photo» in other contexts, «Illustration» in other contexts etc.
Then what makes you expect that servers will do that?
So, Jacques, do you think fighting for an accessible Web is spitting in the wind? Clearly you stopped fighting for accessible math on the Web if all you do is blog about it once in a while.
If you want people to "do the right thing," you have to make it easy for them to do so.
Getting people to do the right thing is never easy. Fighting for civil rights isn't easy. Fighting to ban smoking in public places isn't easy. Fighting for a clean environment isn't easy. And neither is fighting for an accessible Web. If that's spitting in the wind, then [spit.....].
So, Jacques, do you think fighting for an accessible Web is spitting in the wind? Clearly you stopped fighting for accessible math on the Web ...
Thank you for illustrating my point so succinctly. "Fighting" is exactly the wrong metaphor for advancing the cause of accessibility. Perhaps the adrenalin rush of a fight makes you feel good. But advances the cause of accessibility? Not so much.
... if all you do is blog about it once in a while.
I don't blog about accessibility, as some feel-good consciousness-raising exercise. To the extent that I blog about it at all, I blog about solutions that can improve accessibility and usability. Sorry if that makes me a traitor to the cause ...
Anne, maybe you can answer me on this question. You and many others who want to make the alt attribute optional have no experience with accessibility whatsoever. There are experts in accessibility who are telling you guys that optional alt is a bad idea. What's it going to take for you to accept their expertise?
Classic argumentum ad verecundiam.