Can the alt attribute be omitted without hurting accessibility?

In the current editor’s draft of HTML 5, it is suggested that the alt attribute for img elements should no longer be required. The reasoning is that in some cases alt text will be omitted, regardless of whether it is required or not, so it might as well be made optional. Otherwise some authoring tools will automatically insert empty, repeated or meaningless alt text. At least that’s how I understand the reasoning explained in Why the Alt Attribute May Be Omitted.

Basically it seems to come down to “Many people and many tools aren’t using the alt attribute properly, and adding alt text to images uploaded to online photo galleries like Flickr is too much work for end users and tool developers, so the alt attribute should be made optional.” Is that really the best solution though?

To help authors write useful alt text, the HTML 5 specification should provide guidance on that. I am pleased to see that the section describing the img element in the current draft does that well, except for the first example which seems a bit too long (and contains information that all users would benefit from). The rest of the examples are good. They could be worked on, but they are good.

Despite that guidance, there will always be cases where alt text is missing, either because of broken authoring tools or because of author ignorance or laziness. So the specification needs to define how user agents should handle missing alt attributes. In no way does that necessarily mean that images with missing alt attributes should be valid HTML 5.

Concerned that omitting the alt attribute might lead to increased problems for users of assistive technology, most notably screen reader users, Steve Faulkner conducted a series of tests. During the tests, Steve recorded the output from a screen reader confronted with pages containing images with and without alt attributes. The results and his conclusion are presented in Investigating the proposed alt attribute recommendations in HTML 5.

If you read Steve’s article you will see that omitting the alt attribute leads to the tested screen readers announcing the value of the img element’s src attribute when an image is in a link. In many cases the filename contained in the src attribute is pure nonsense that does not provide the user with any useful information about the image.

The text-only browser Lynx has similar behaviour to the screen readers Steve tested in that it displays the filename of linked images that have no alt attribute.

The HTML 5 draft somewhat cryptically suggests that Non-visual user agents should apply image analysis heuristics to help the user make sense of the image. It would be very interesting to learn more about how those heuristics are supposed to work. Have vendors of non-visual user agents been consulted to find out if this is at all possible? How are non-visual user agents supposed to figure out the author’s intent by analysing an image?

Omitting the alt attribute clearly causes problems in some cases, so it is not a very good option. I have seen suggestions of a couple of other solutions that I think are better, though neither is perfect.

One is to add a noalt attribute that is to be used when alt text for some reason cannot be specified. I think it is a much better idea than simply allowing the alt attribute to be omitted since it makes it explicit that the author (or authoring tool) has intentionally not supplied an alt text. This would make it easier to use validation to check for mistakenly missing alt attributes.

Another solution could be that the alt attribute may be omitted only if the image is inside a figure element that contains a legend element, the contents of which may then take the place of alt text. An example from the current editor’s draft of HTML 5:

  1. <figure>
  2. <img src="1100670787_6a7c664aef.jpg">
  3. <legend>Bubbles traveled everywhere with us.</legend>
  4. </figure>

In this case the text in the legend element can give the user at least some indication of what the image contains, and would be much better than being presented with the image’s filename.

To me, both of those options seem much better than simply making the alt attribute optional.

One problem remains though. To be backwards compatible with current Web content I believe screen readers (and any other user agent that does not, permanently or temporarily, support images) will need to keep announcing or displaying something when the alt attribute is missing. In most cases the only thing available for them to display will be the image’s filename, which as we have seen is often useless.

So, after much thinking back and forth on this subject, I’m not convinced that making the alt attribute optional is a very good solution. Gez Lemon seems to share my opinion, and explains his reasoning in The HTML 5 Image Element (where he also brings up the longdesc attribute, which is missing in the current editor’s draft of HTML 5).

Like Gez, I believe that we need to keep encouraging the developers of authoring tools and applications like Flickr to improve how their systems handle alt text. Making the alt attribute optional won’t help – it will only lead to lazy and ignorant authors and tool vendors ignoring it completely.

Posted on September 7, 2007 in Accessibility, HTML 5

Comments

  1. Hmmm, I’m ambivalent about this. There are times I use images just for layout matters, say a rounded border. It doesn’t really hurt when those images are not displayed, and what I don’t want in those cases is a text to be displayed, so I leave the alt-attribute empty. I also don’t understand the difference between a noalt-attribute and an emtpy one. In both cases I clearly state that I don’t want an alt-text to be displayed.

  2. Rolf, I disagree. Firstly rounded borders are layout not content so shouldn’t be in img tags (and the recent arguments about the idealism of content/presentation separation do not apply here). But I do tend to agree that there might be situations where content images just don’t have an appropriate textual description.

    The difference between an empty alt attribute and a noalt attribute is that you are clearly saying to user agents “I am aware I should be using alt text, but there just isn’t any that’s appropriate - non visual agents can safely ignore me”, whereas an empty alt attribute suggests a WYSIWYG editor was used or that someone just shoved the alt in for validation and no other reason.

    Effectively it’s a more descriptive kind of exception handling, instead of “something has gone wrong” it’s “something has gone wrong and I know why”.

  3. I don’t really see a problem with the current method of leaving the alt attribute empty if the meaning of the image is irrelevant or is already expressed in surrounding text.

    However, layout-related images like in Rolf’s example should be defined in CSS.

    I was tidying up the markup for a DIY guide on a site which consisted of an ordered list with an image in each list item, followed by the description of that step.

    I actually had to fight to empty the alt attributes. People think that every image must have an alt attribute which describes the image, which in this case was usually a duplication of the first sentence of the list item’s text.

  4. I was just thinking, how about making noalt descriptive as to the reason why there’s no alt text.

    ie something like noalt=”implied” or noalt=”no-description”

    Something that tells screenreaders why there is no alt text, not just that there is no alt text intentionally.

  5. On the one hand, I may wish to deliberately use no alt (for decorative images). From a semantic point of view, it makes no sense to me to have to explicitly include an attribute I’m not using.

    From an accessibility point of view however, I clearly understand it. It allows assistive technology to understand that I am explicitly stating “this has no alt value”, rather than leaving them wondering whether I’ve missed it out by mistake or whether it is deliberate.

    As I agree that the correct answer to “people are doing this wrong” is not to suddenly proclaim that the wrong way is right after all, I’d rather keep the status quo.

    It ought to be the responsibility of the content to provide an appropriat alt (null or otherwise). If the content can’t provide an appropriate one, then that’s up to them - but let’s not pretend that it’s correct.

    Okay, Flickr and the like may not know what the appropriate tag for an image is going to be, but for the most part they can have a reasonable guess: use the image title?

    Alternatively, why don’t they improve their interface and make the input of alt text when people are submitting photographs mandatory?

    Let’s not allow bad practice to be formally incorporated into HTML…

  6. Let’s walk a big fucking circle around the current problems with HTML and accessibility and discuss something like this. Great.

    Of course alt attributes can be omitted. People who know what alt text is and what it’s for will use it. Other people ignore this “alt text you speak of”.

    If you explain your clients they will rank better in google if they carefully write alt text in the CMS, and if the client cares about the SEO part, they will do it. You can’t make them care about the accessibility part. If they’re good natured they will do it for both reasons.

    90% of whatever is an image can’t be described or is just decoration to the text next to it. No blind person is waiting in line for clumsy alt text along the lines of “This is a big tree with brown leaves”.

  7. September 7, 2007 by Rommert

    I think the alt attribute can be omitted. The only use the alt attribute really has (that I know of) is describing what the image is about when it’s a functional image i.e. a button of some sort. An alternative is using an image for a text replacement, but from a semantical point of view I should use a way of CSS image replacement on a paragraph of text.

    So, in my opinion, the alt attribute is only necessary when the image is functional. They say a picture says more than a thousand words, so even when a image is supporting a piece of text an alt attribute can’t describe the full meaning of the image. The alt text would become to long. So in that case something like a supporting legend would become more semantical and, in this case, the writer should pay attention to the supportive image used and write the correct description.

  8. Now I’m no expert on webstandards but the way I code webpages I often come across a situation where a header contains the same text I feel would make sense to put in my alt-text and since duplication of data doesn’t make sense in my mind I often end up with an empty alt-text in those situations.

    My solution is probably not the “right” solution but it makes sense to me if I would be allowed to omit the alt-text if I’ve taken care of explaining the image elsewhere on the page. Perhaps that could be done by a figure but having an image emphasizing the header of an text really falls out of the scope of a figure.

    I don’t know any solution - but that’s the situation I’ve gotten into quite often. Having an image with a header below and then the text and having that the image’s alt-text would be the same as the header because I feel a need to have it there even for those people who are able to see the image.

  9. September 7, 2007 by Roger Johansson (Author comment)

    A clarification. This is not about using empty alt text, it’s about omitting the alt attribute altogether, leaving it to the user agent to somehow figure out if the image is important or not. Images that convey no essential meaning and are not linked should be given an empty alt attribute to let user agents know they can be ignored.

  10. If the intent is to drop the alt attribute, then the img tag could be more like object tag:

    <img src="image.png">Alternative Text</img>
    

    It would be interesting and would allow an better text management in my opinion.

  11. I see no difference in result between an empty alt attribute and omitting the alt attribute. The result is the same: no alternate text. Don’t make things complicated with things like “implications of the author”.

    I also think that forcing people and CMS software to fill the alt attribute is not any help to handicapped visitors. An automatically generated alt text of “DSC01438”, “” or “picture” for a picture of your dog is not going to help anybody.

    Instead, something that should help is to teach CMS software developers how to better integrate alt attributes into their CMS, e.g. by letting the user choose a descriptive title for their freshly uploaded images.

  12. Roger, I’m so glad that you second our (ok, most of us) thoughts regarding alt attribute. I think it’s insane for HTMLWG to just throw it away. Because this is what is going to happen - now even alt="" advertises the existance of alternate text. Without “MUST” in spec. people will stop adding it. It’s a big no-no. I can reconcile myself to existance of <font> because our 5% of semantically correct web isn’t dominating of course but people at HTMLWG act like they don’t know how accessibility is propagated and advertised to people on the top, with money.

  13. SEO arguments aside, how useful is the alt text for people who use screen-readers? Like Wolf said, ‘No blind person is waiting in line for clumsy alt text along the lines of “This is a big tree with brown leaves”.’

    Everything that I’ve read about this subject was conjecture from people guessing what the web experience is like for a blind/low-vision user. Are there any actual studies or even anecdotes from users that actually DEPEND on screen-readers?

  14. Well, it seems to me that getting rid of the alt tags all together is a huge mistake. Instead, why don’t we encourage sites like Flickr to generate alt text through the tag names given by users who upload their photos to the site? I know this is not always going to be specific enough becuase users will use tags that aren’t specific to the photo but specific to searching for the photo, but at least it will put things in the same realm.

  15. September 7, 2007 by Zephyr

    “adding alt text to images uploaded to online photo galleries like Flickr”

    Roger, I’m wondering how useful alt-text would be on photos in Flickr. Would someone who is blind want to browse photos? Or am I taking too narrow a view of accessibility, overlooking benefits for other users? They already employ tags, so alt-text would not add much for findability (looking for photos by keyword search). Any thoughts?

  16. Agreed. I think in most cases the contextual information around the image is far more useful than the actual alt text.

  17. I think the last place you want to be when you’re blind is flickr.

    • also wondering about studies, because even my opintion is estimated guesswork.
  18. The <legend> element is not a replacement of the alt attribute. The HTML5 spec gives a stupid example where the legend is the same as the alt. In most cases, legend is used to provide credit or copyright info for the image such as “Courtesy of CNN.com”.

  19. Not to derail the conversation, but using the legend element for credit/copyright info is semantically incorrect. Using the cite element within figure would probably make more sense.

  20. I think what I oppose the most is the reasoning that: “since so many people already do it wrong, let’s omit it”…

    I think that about as many people don’t care about web standards, validating, accessibility etc, so with that logic, is there any reasoning for HTML 5 to exist at all?

  21. Let me make a simpler example were <legend> is not the same as alt text. I think everyone will agree the most common usage of <legend> will be “Figure X”.

  22. As just a wild idea, what about an “alt || noalt” validation requirement, i.e. img requires one of them? This would allow designers that want and know where to use the alt tag to continue to semantically describe their content, and those images that really have no value to a screen reader to be easily ignored.

  23. Or just require alt to be a length greater than length of zero?

  24. Giving individuals uploading photos to flickr or others like it the ability to add alt text is a little silly, how many people are going to know what alt text is or know what to put in.

    Omitting the alt attribute is a bad idea, most screen readers have a hard enough time with current code standards, so lets not throw more crap at them.

    A weird concept, how about we teach people about CURRENT standards and enforce their usage. Do not omitt something as important as the alt attribute simply because so many CMS and WYSIWYG applications have been built for people that only know a tool instead of the code. If you take probably 80% of the “web developers” out there, take their CMS or WYSIWYG tool away, they would never be able to complete a project.

  25. Since alt is suggested to be optional rather than dropping it, I don’t see any problem with that. Not every image can be described like that (I mean meaningful and useful description here), well besides smilies and some others as well.

    The only difference between empty alt and absence there of is that some browsers display “image” (or something similar) when alt is ommited, and nothing if there is no alt. And it’s kind of hard to click an image and choose “display image” option if you can’t see it in the first place. It’s more of a browser behavior here.

    This starts to sound like MS and HTML5 thing, when they need explicit switch for it and for some reason “doctype html” is not enough… i.e. “noalt” attribute would not add even a tiny bit useful info. Chosing this road maybe we’ll end up with something like, say, noid, nocite, no-accesskey, no-whatever-else as well…

  26. err… I mean, browsers display “image” (or something similar) when alt is ommited, and nothing if there is alt=”“.

  27. I am wary of the noalt idea because then you are likely to just get software that produces noalt by default thereby creating valid pages - too similar to making it optional in my view.

    I am also wary of the legend version simply because my instinctive view wonders if we’re just going to make new containers (in the divitis vein) to hold everything… bloating markup - but I have to say that comment is just my ignorance or the time of the morning. Nevertheless I’m wary of it.

    I really object to the idea that because most people don’t use alt correctly then its not worth keeping. Doesn’t that relate to DOCTYPE as well, and for that matter any standard. Most product on the net IS junk code when you think of it. We’re meant to be pushing against that perspective not rallying to dumb down for Flickr at the cost of Jaws.

    Neither do I know the answer to this one. I’d say while in doubt keep the alt as it is because nothing can make any developer write high quality alt. But having it there allows for high quality alt if they are interested in providing greater use for their customer / site visitor.

    Why not make a special DOCTYPE for Flickr called HTML5 Apathetic which allows them to validate as not caring about alt and other things - similar to the humourous frameset option in XHTML 1 …

    HTML 5 Apathetic could also exclude whatever the devloper likes in fact - except the Apathetic Doctype of course. Now that would just be plain silly, how would they validate Apathetic without a Doctype.

    Catering for the lowest common denominator of effort will always bring us back to the person(s) who want a free pass and a tick for being valid something, whatever it is.

    My question. What information about an image will a noalt actually supply to non visual users that makes it worth having? Its a negative. Would it be easier to keep the empty alt text in such cases and agents accept there is a vacant lot in there anyway?

    I’m really disenchanted by the noalt conversation with HTML5, Roger.

  28. HTML 5 Apathetic would really solve all problems by making everything optional :-)

    Even if it’s ignored or misused by many - maybe even the majority, the alt attribute should be required.
    A short alt-text may not tell all that much about an image, but it is, IMO, in most cases better than nothing. If we think the image doesn’t need alt-text, the emtpty alt works just fine as is.

  29. all you blaming HTML5 of simple solutions you should get your feed on the ground and reconsider it.

    when we stick to reality, we found out that lot of existing image elements serve for layout. Unless there are multiple backgrounds on one element possible this is and will be SAD REALITY.

    OK, world is not perfect, lets cope with it. Its meaningless to provide the alt attribute for them or even require it for validity.

    agreed? lets move to more important items on the long list of html 4.01 flaws.

  30. Condoning bad practices, such as allowing alt attributes to be completely absent for images that are actual content is wrong. It is a cowpath that HTML5 should not pave.

    The answer is:

    1. Tools/web services that adhere to ATAG and have the ability/features to generate good alternate text, and
    2. Educating and encouraging users to use those features.

    For instance, XStandard prompts the user to identify if an image is decorative or not. The user makes the decision. If they say the image is not decorative, and in fact actual content, they must submit alt text before the image can be saved. For more info visit XStandard Developer’s Guide.

    To ensure that accessibility requirements are addressed and improved and not bypassed and abandoned, the HTML 5 WG should work closely with and be advised by WAI. Adhere to the recommendations, which the WAI has produced. The HTML 5 Working Group should ask for guidance when out of their field of expertise. That is in the group’s charter.

    WCAG 2 Guideline 1.1 says, "Provide text alternatives for any non-text content so that it can be changed into other forms people need such as large print, braille, speech, symbols or simpler language".

    The Techniques for WCAG 2.0 F65 document says, "Failure of SC 1.1.1 due to omitting the alt attribute on img elements, area elements, and input elements of type ‘image’"

    "This describes a failure condition for text alternatives on images. If there is no alt attribute, then assistive technologies are not able to identify the image or to convey its purpose to the user."

    "Some Assistive Technology might attempt to compensate for the missing alt text by reading the file name of the image. But it is insufficient to rely simply on the file name for many reasons. For example, file names may not be descriptive (e.g., images/nav01.gif), and technology specifications do not require descriptive file names. Some assistive technology may not read the file name if alt text is absent."

  31. Having ‘alt’ as an optional attribute would only promote more laziness and misuse of it.

    Having a ‘NoAlt’ attribute would spawn a rash of nonsense image meanings on the web for visually impaired users….and yet more laziness too.

    I like Andrew’s suggestion:

    “…something like noalt=”implied” or noalt=”no-description”

    But isn’t this just repeating the same lack of thought about which description to use?

    How about re-enforcing the validity of the ‘alt’ attribute with HTML 5, making it more necessary to use it properly?

    Robert: Yeah, why should we have HTML 5 at all? :D

    Stephen: You’ve just (already - that was quick!) written about this on your site - so I’ll respond further to your comments on there.

  32. How about we keep the alt attribute and when you can’t think of anything meaningful to put in it, change the attribute to f*ckitalt.

    When there is no alternative, f*ckitalt. Simple and easy to remember. =)

  33. You say that “making the alt attribute optional won’t help – it will only lead to lazy and ignorant authors and tool vendors ignoring it completely”. But the implied corollary to this is that requiring the attribute in all cases (even when no alt is available, which is the only case where the attribute is allowed to be omitted per the current draft text) will lead to lazy and ignorant authors and tool vendors not ignoring the attribute. Unfortunately, that is provably false: alt attributes are omitted and poorly filled in all over the place.

  34. I agree entirely.

    As you’ve clearly described for other similar issues, the solution is to solve the problem, not the symptoms.

    The real solution is better accessibility awareness by site and tool creators, not simply making the standards/specs lax and saying “no, actually it’s OK to be ignorant/lazy”.

    The alt attribute should not be optional, if no alt text is applicable for some reason (I can’t think of any off the top of my head) then simply specify that: alt="".

    If that leads to confusion between intentionally blank alt text, and mistakenly missing alt text, well personally that’s an authoring issue; don’t leave alt attributes blank (e.g. “I’ll do it later”) unless they’re actually ment to be blank. Fill it in immediately, or leave the alt attribute out completely and enter the text later when the validator catches the error.

  35. September 9, 2007 by steve faulkner

    Ian Hickson wrote: “even when no alt is available, which is the only case where the attribute is allowed to be omitted per the current draft text”

    This statement does not appear to be correct. From the spec there are 3 cases where the alt attribute is allowed to be omitted.

    1. no alternative text available

    2. Sometimes there simply is no text that can do justice to an image.

    3. When an image is included in a communication (such as an HTML e-mail) aimed at someone who is known to be able to view images, the alt attribute may be omitted.

  36. What is so hard for user agents to assume that alt=”” is a decorative image with no inherent meaning? As compared to noalt which really does what again? The real life difference to me appears to be not about that user agents can’t identify that alt=”” as meaning no meaning, nor about changing because people don’t author correctly (because they STILL won’t author correctly with noalt - am I correct?) - but the difference boils down to the idea that ‘alt should not be required’ of authors to get a tick of approval.

    Seriously authors can currently write whatever slop they want anyway in the real world - its just that it isn’t as per the specs… browsers tolerate a lot of rubbish. So its about ‘not requiring authors’ to use alt to get a validation tick.

    In contrast the alt is currently useful if used correctly. Yes if. But introducing noalt in no way improves that if. Not that I can see anyway.

    Its just my opinion but until noalt really is explained, and until I could see how the cure assists screenreaders for example rather than hinders, it would be very unlikely I would work with a standard that is in my opinion going backwards. Others may disagree and that’s fine.

  37. The problem with the noalt attribute is that it doesn’t actually solve any of the problems with omitting alt (the image is still just as inaccessible). All it does is provide an indicator to the validator that the omission was intentional, which I don’t think is necessary because validators can issue warnings about missing alt attributes anyway.

    Also, the issue isn’t just that some authoring tools are broken and don’t allow users to specify alt text, it’s that even if users could provide it, many people won’t. There are people who say that education is the answer and that all users should be forced to provide it, but in reality we have a hard enough time educating web developers, let alone average users who just want to share photos with their family and friends.

    The question, for which I am yet to get a clear answer, is after prompting the user for alt text, what should authoring tools insert when the author still fails to provide it?

  38. @Lachlan:

    Authors can’t fail to provide alt text if the authoring tool requires it!!! Does that answer your question?

    Just look at the xstandard example mentioned above. That authoring tool does not let authors insert an image unless alt text is provided for informative images. And that tool does not let authors enter alt text for decorative images. And according to their site, xstandard has a tool (wheelchair toolbar icon) that lets authors check if the alt text makes sense.

    David

  39. David, that approach may work for an HTML editor aimed at web developers, but consider how such an approach would seriously affect the usability of a site like Flickr for average users? What about when users batch upload their photos? What about dealing with all the existing images on Flickr? What about embedding an image into an email?

    Do you really think it would be effective to prevent a user from continuing until they have provided alt text in all use cases? You can’t make the problem go away by unconditionally saying that all tools should force authors to provide alt text. It won’t work in all cases and the problem will still exist.

  40. @Lachlan

    There are shortcomings with the alt attribute, but making it optional doesn’t appear to solve any of those.

    My authoring tool leaves the alt attribute empty if I don’t provide a text, and I can insert or change an alt text whenever I like. That doesn’t solve any of the old weaknesses, but it doesn’t add any new ones either.

    I don’t think a standard will change anything for those who don’t adhere to it, so if we want a standard that everybody follows then we will probably end up with something closer to the “suggested” HTML 5 Apathetic anyway. Seriously: that can’t be the goal of a standard - any standard.

  41. So what does this really mean? It means that sites that don’t validate because they fail to put an effort into finding a text alternative. I think if HTMLWG has any business doint something like that they need to do it in agreement with WAI and WCAG 2. What kind of message would having conflicting guidelines send? Think of that. WCAG 2 requires alternative text and that’s not likely to change. If HTMLWG doesn’t think this important enough to require it they might as well be saying WCAG’s not really required either.

  42. September 10, 2007 by steve faulkner

    lachlan wrote: “The problem with the noalt attribute is that it doesn’t actually solve any of the problems with omitting alt (the image is still just as inaccessible). All it does is provide an indicator to the validator that the omission was intentional”

    I think you are missing the point of the noalt attribute (not that I am endorsing this method).

    The noalt would provide a clear indication that the image has no alternative text, but contains “critical content” rather than just being a decorative or layout image that the author has not provided an alt attribute for due to ignorance or laziness. Presumably then UA could treat such an image differently from other images that have no alt attribute. One problem that this method has is backwards comaptibility.

    lachlan wrote: “The question, for which I am yet to get a clear answer, is after prompting the user for alt text, what should authoring tools insert when the author still fails to provide it?”

    This is dependent on the context the image is used in and the context in which it is being authored. Flickr.com continues to be used as an example by proponents of the “optional alt”. I have provided research showing the deleterious effect this would have on what is announced by screen readers in one of the major contexts that images are used in photo sites (as the sole content of a link) such as fickr. I have twice requested more examples from the HTML working group (3 urls provided so far)in order to do further research and be able provide a practical response to questions such as yours.

    lachlan wrote: “What about when users batch upload their photos? What about dealing with all the existing images on Flickr? What about embedding an image into an email?”

    Looking at how flickr deals with it currently by using the meta data it has available to it for the alt attribute, while being far from ideal, is better than no alt attribute. At least for screen reader users something intelligible is conveyed to them.

    As far as emails are concerned, the spec clearly states the only case where it is legitimate to omit the alt attribute: an email “aimed at someone who is known to be able to view images” So in this case an empty alt=”” could be used with no ill effect.

  43. Steven Clark said in his comment above, “Seriously authors can currently write whatever slop they want anyway in the real world - its just that it isn’t as per the specs… browsers tolerate a lot of rubbish. So its about ‘not requiring authors’ to use alt to get a validation tick.”

    Maybe it is actually more about “certain” HTML 5 working group members getting validation ticks on their own flickr pages.

  44. I don’t think there is an easy answer to this, but for decorative images it always seems semantically strange to specify alt=”“. Specifying noalt or missing out the attribute altogether would be better. At the moment user agents like Jaws do have problems when there is no alt attribute, but there is no reason why they could not be coded to make the assumption that if there is no alt attribute then none was intended.

    There is also a responsibility on authoring tools as well to ensure that code produced is at least valid. It’s not rocket science.

  45. I think that if the img is used then the image is content and so it needs to use alt. If many people don’t use it, that is not my problem. After all many people use AJAX or even tables the wrong way and that is not an excuse for us. We won’t start doing things the the wrong way, just because millions do it.

    So, IMHO and AFAIK the alt should be used every time the img is used. Decorative images should always

  46. I think that if the img is used then the image is content and so it needs to use alt. If many people don’t use it, that is not my problem. After all many people use AJAX or even tables the wrong way and that is not an excuse for us. We won’t start doing things the the wrong way, just because millions do it.

    So, IMHO and AFAIK the alt should be used every time the img is used.

    Decorative images should always be on the CSS and not on the XHTML

  47. September 12, 2007 by Steven

    When displaying keys or legends for diagrams, for example, when identifying the meaning of icons on a map you would have the image and a plain HTML description of the image beside it for all to read, not just for those who cannot view images. If you included an alt tag here, the screen reader would essentially have to read the same text twice. If I was visually impaired this unnecessary repeating information would really bother me.

    Plus, why inflate code with noalt when it does not provide assistance to anyone or anything. In the same way, empty alt tags inflate code too. Drop them if they are not necessary, but be responsible developers and include them when they are necessary.

  48. At this point in time, I am completely against making the alt optional or removing it from any specification. To be honest, the way it sounds lately, if the HTML5 working group is going to come up with a new specification that will cater to people who don’t want to take time to do it correctly, then it’s not going to achieve success in the long run because a good portion of the web design community will perceive it as a second-rate/lower-tier spec.

    As far as companies that deal in large amounts of images, the could easily adjust their interface handling to accommodate the standards. For instance, flickr has a little description box for every photo. That description could be applied to the ALT attribute automatically as well as being displayed separately as it is now. They could even get strict about it and not allow photos to be flagged as public until they have a description typed in, but still allow them to be uploaded.

    Another option would be to rework the HTML rendering so that it does not create IMG elements, but instead creates OBJECTS, and inserts the description text as the OBJECT text alternative if images are off.

    There are plenty of applications that already immediately ask the user for a description when inserting images (WordPress for example). They don’t have to call it an ALT attribute because the general user might not know what that is, but they can definitely ask for a ‘description’ and use it for the same. In my opinion, that’s better than blank alt text or removing the alt altogether.

    If they wouldn’t do that, and only wanted to consider the choice between using the file name for an alt text or leaving it blank, then I would say AT LEAST put the file name (not that its usually descriptive when coming off cameras).

    For the entire argument about decoration images with blank alt attributes - well, we already know that’s not a good method anyway because your decoration images that would have a blank alt shouldn’t be in an IMG element anyway.

  49. September 13, 2007 by Steve B.

    OK, hang on, this is going to be a bumpy ride.

    @ Erik

    "As just a wild idea, what about an "alt || noalt" validation requirement, i.e. img requires one of them? This would allow designers that want and know where to use the alt tag to continue to semantically describe their content, and those images that really have no value to a screen reader to be easily ignored."
    

    Those images that have no screen reader value should have an empty alt element at least, or be presented vis CSS (which most screen readers ignore).

    @ emilk

    "when we stick to reality, we found out that lot of existing image elements serve for layout. Unless there are multiple backgrounds on one element possible this is and will be SAD REALITY."
    

    Images solely for layout? Yes, SAD. Very sad, indeed. that this is still the case. Very unprofessional, too.

    "OK, world is not perfect, lets cope with it. Its meaningless to provide the alt attribute for them or even require it for validity."
    

    The world is not prefect, but don’t you think the whole idea of standards is to make it better? Should we not advocate the inclusion of as many people as possible. Do you actually believe we should “flip the bird” to people who are different than the rest of us?

     "... lets cope with it."
    

    This is the road to apathy. Do we really want to go there?

    "agreed? lets move to more important items on the long list of html 4.01 flaws."
    

    Agreed? Not in this lifetime!

    @ Steven

    “If I was visually impaired this unnecessary repeating information would really bother me.”

    That is the key phrase “If I was visually impaired …” You are, obviously, not visually impaired. What gives you the insight, the knowledge, the ultimate control and authority, of what a truly visually impaired user want/needs Many (most) authors do not include redundant textual links. Isn’t getting the information twice better than not getting it at all?

    "Plus, why inflate code with noalt when it does not provide assistance to anyone or anything. In the same way, empty alt tags inflate code too. Drop them if they are not necessary, but be responsible developers and include them when they are necessary."
    

    Empty alt elements (as you say, “tags”) are usually ignored by most popular screen readers and thus not read at all. Since this suggestion is analogous to the debate at hand, why is this any more constructive than dropping the element?

    Adaptive computer technologies often lag quite far behind any new web development standards. Anything decided “today” will invariable take two or three version releases to show up in even the most active adaptive computer technologies.

    Now for the coup de gras, why is the topic of accessibility only focussed on screen reader users? They indeed have a very strong lobby group(s), but they are actually in the minority of users of adaptive computer technologies. Something to think about.

    And just in case you want to reply with a derogatory comment, Yes, I’ve been called that before. I actually work in a field where we support people with all types of disabilities.

  50. September 13, 2007 by Isaac Lin

    To those who think tools like Flickr should enforce the entering of descriptions: Do you think that YouTube should only accept videos that have captions (or even just those with accompanying text transcripts)? After all, a text equivalent is required by WCAG 1.0. In any case, if Flickr ever made entering a description compulsory, shortly afterwards people would invent workarounds to automatically populate the field with text (likely a fixed string).

  51. I think that using the alt attribute is a must. Doing so you clearly provide alternative text. And if the alt is empty, then it means that image doesn’t need alt for some reason.

    And if the alt attribute is omitted as recommended, how a user agent can understand, is there no alt because of bad coder? or because of meaningless image?

    I’m completely agree with Roger:

    “Making the alt attribute optional won’t help – it will only lead to lazy and ignorant authors and tool vendors ignoring it completely.”

    Thank you for posting it.

    We have to think about how can we force developers to put good alt’s, not to allow them omit it, haven’t we?

    (I’m sorry for my English)

  52. To answer the question of why a blind person would use Flickr, first, stop thinking that “blind” means “totally blind.” I have first-hand experience that low-vision kids all have digicams, all take pictures, and all look at them on computers and upload them.

    These kids may or may not be blind enough to require alt text.

    Additionally, every 18 months or so there’s another newspaper article about a blind photographer having an exhibition.

    Putting all the above aside: The whole point of accessibility is to provide people with options. It isn’t up to us to dictate whether or not a blind person should or should not be interested in a site.

  53. I don’t read all post, but from 1 to ~12 few people speak about CSS for graphical purpose. I think the alt attribute should be kept due to his semantic/informative value.

    1. If you don’t need an alt value that mean that your image have a design purpose then use CSS
    2. Else your image mean something then you need an img tag and his alt attribute

    So noalt attribute is worthless.

    alt have an accessibility and a technological role to play:

    • help people with disabilities;
    • for search engine accurancy and other “data mining” of the future.

    That why alt should be kept.

  54. @lyhana8, @Steve B.

    you theoretics, if the is no way how to attach multiple background images to say all four corners of a header element. can you tell me precisely how should i solve this nowadays with pure css without introducing an element?

    with noalt you just add complexity and create other problems instead of solving the one we have.

  55. I agree totally with you on this Roger.

    If developers are omitting meaningful alt attributes when it is compulsory, what would they do when it’s optional?

    It’s taken a long time to get everyone to the stage they’re at now, we just need to keep on “encouraging”.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.