The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Why the Alt Attribute May Be Omitted

by Lachlan Hunt in Browsers, Elements, Processing Model

The specification of the alt attribute was recently worked on to thoroughly improve its definition, including an in depth explanation of how to provide appropriate alternate text, with clear authoring requirements.

The requirements describe situations where alternate text must be provided, where an empty alt attribute must be used and, most controversially, where the alt attribute may be omitted entirely. This is controversial because at first glance, it seems like an attempt to endorse the bad and inaccessible practice of omitting the alt attribute, and thus yet another slap in the face for accessibility. That is an unfortunate misconception that needs to be carefully examined to settle any concerns people have. Although it may seem backwards, the situation is actually much more positive.

There are many observed cases where alternate text is simply unavailable and there’s little that can be done about it. For example, most users of photo sharing sites like Flickr wouldn’t have a clue how or why to provide alternate text, even if Flickr provided the ability. While everyone agrees that it would be wonderful if all users did – indeed, the spec strongly encourages that – most users simply won’t.

The problem being addressed is what should be done in those cases where no alt text has been provided and is virtually impossible to acquire. With the current requirement for including the alt attribute in HTML4, it has been observed that many systems will attempt to fulfil the requirement by generating alternate text from the images metadata.

Flickr, for example, repeats the images title; Photobucket appears to combine the image’s filename, title and the author’s username; and Wikipedia redundantly repeats the image caption. The problem with these approaches is that using such values does not provide any additional or useful information about the image and, in some cases, this is worse than providing no alternate text at all.

The benefit of requiring the alt attribute to be omitted, rather than simply requiring the empty value, is that it makes a clear distinction between an image that has no alternate text (such as an iconic or graphical representation of the surrounding text) and an image that is a critical part of the content, but for which not alt text is available. It has been claimed that Lynx and Opera already use this distinction. For images without alt attributes Lynx shows the filename and Opera displays "Image", but neither show anything for images with empty alt attributes. It is still somewhat questionable whether this distinction is actually useful and whether or not browsers can realistically make such a distinction with real world content, and that is certainly open to debate if you have further evidence to provide.

It has been suggested that taking away the unconditional requirement for the alt attribute will affect the ability of validators to notify authors of their mistakes and take away a useful tool for promoting accessibility. However, using validation errors as an accessibility evangelism tool is not necessarily the only, nor the best, way to address the issue.

While it is indeed very useful for authors to know when they have mistakenly omitted an alt attribute, attempting to unconditionally enforce their use, using a tool as blunt as a validator, is counter productive since it encourages the use of poor quality, automatically generated text. Besides, nothing will prevent conformance checkers and authoring tools from notifying authors, if they so desire.

No practical accessibility benefits are lost by conceding the fact that you cannot force everyone to provide alternate text and making the alt attribute optional for the purpose of document conformance. No-one is claiming that conformance to HTML5 equates to conformance with accessibility requirements. There are lots of things that are considered technically conforming in HTML, yet still inaccessible if used poorly. Making alt technically optional doesn't stand in the way of accessibility requirements, nor greatly impact upon accessibility evangelism. It just acknowledges the reality of the situation in the hope of reducing the prevalence of poor quality, automatically generated alt text.

↔

46 Responses to “Why the Alt Attribute May Be Omitted”

  1. I always use the alt tag regardless. Isn’t it required for accessibility these days? I use it for SEO purpose.

  2. I always use the alt tag regardless. Isn’t it required for accessibility these days? I use it for SEO purposes.

  3. It’s not a tag, Lachlan just explained its accessibility effects, and if you’re using it for “SEO” purposes your pages probably will not make much sense in text-only renderings.

  4. You claim that allowing the absence of alt text makes it possible to differentiate between cases where alt text is not available and is never going to be available on that page and other cases where the author has made a specific decision to use a null alt text.

    However, permitting the absence of alt does not differentiate between the case mentioned above and the much more common case of not knowing there is an alt text or not caring (“most users simply won’t” provide an alt text). In either case, you end up with an inaccessible image, and by implication you are presenting that as some kind of progress for HTML.

    Your examples of Flickr, Photobucket, and Wikipedia are examples of incorrect software implementation. Contrary to your claim, yes, absolutely every author should be forced to make a decision about an alt text for every image, whether to write a real alt or to go with null text. It is of course known that a blind person cannot reliably write an alt text for an unfamiliar image.

    You have not improved accessibility, though you claim you are not harming it, and you have further solidified the impression that the WHAT WG always had a list of things they wanted to get rid of, and even the first principle of Web accessibility, alternate text, is one of them. Your proposal is not “much more positive” than your critics think; it’s actually worse than we imagined.

  5. Joe, no-one wants to get rid of the alt attribute, and assuming you read the spec, you would have noticed that it goes great lengths to explain how to write good alt text. As I explained in the article, we’re trying to address the problem of crappy tools generating poor quality alt text, which is considered worse than providing no alt text at all.

    If you have another solution to the problem, we’d be happy to hear it. In other words, what would you require sites like Flickr and Photobucket to generate for their alt text, and why would that be better than simply omitting it?

  6. I completely agree that no alt text is better than poor alt text. I also think that the HTML5 specification does a much better job of defining how to write a good alt text than HTML4, so now we at least have a good (and soon to become; normative) place to point to whenever we want to bonk someone in the head because of bad (or missing) alt texts.

    Just as important as the specification, though, is pressuring tool vendors such as Flickr so they produce markup that is universally accessible. Having an HTML specification that does the job of explaining what to do and not to do is very helpful, so this will make that job easier.

    What most people seem to misunderstand with the alt text is that it should follow the flow of the surrounding text. They can’t seem to grasp that when the image isn’t shown, the alt text is read in the flow with the surrounding text and with a bad alt text, it will sound really bad too. I think the HTML5 specification does a wonderful job of getting this point through, so I’m hoping this is going to improve the alt text people provide in the future.

  7. Just curious…

    When “The specification of the alt attribute was recently worked on to thoroughly improve its definition” who was consulted from the W3C WAI PF Working Group before reaching any conclusions? Wer any Accessibility Specialist (such as Mr. Clark, a published author on the subject, or Mr. Jim Thatcher, another published authority, or any other known and respected accessibility experts) invited to comment or participate in this work? Were publicly respected and directly affected organizations (such as the British National Institute for the Blind, who have done an enormous amount of work in this area) invited to comment? Given that the alternative text for images *is* such a serious consideration for many users (including but not limited to the blind), surely the broadest input and opinion would be sought for such important work, before definitive answers could be reached.

    Could you kindly tell us whom you consulted with?

  8. First I would like to note that passionate arguments are counter-productive without a lot of evidence to back them up. Though I agree with Joe Clark, who I respect for his past work in accessibility, his comment, and vague aspersions about the WHAT WG not caring about accessibility, got in the way of me understanding why I agree with him.

    The benefit of requiring the alt attribute is that it’s an undeniable advertisement that alt exists, and a chance to educate the author about proper usage. When a well meaning author validates their pages, they will come across the error, and be notified.

    The abuse of alt that is noted here (repeating text, useless information) is because when authors first discovered that they must use alt, they were given poor instructions.

    With the improved specification of the usage of alt, it makes all the more sense to keep alt as a required attribute.

    If alt is not required, all the existing content with alt abuse will remain. With alt required, there is a better chance that authors will find out how to use it better.

  9. there have been author guidance on the “proper” use of alt text available since 1999 in the form of a W3C Technical Recommendation — namely, the Web Content Accessibility Guidelines, 1.0 published in may 1999, and its extensive techniques documents. there is a decided prejudice against WAI-generated Technical Recommendations and a mis-conception that WAI documents apply only in “special use cases” — this is a prejudice that authors and specification writers alike share. a W3C Technical Recommendation is a Technical Recommendation, as binding as any other W3C-generated Technical Recommendation. there are also, as has been mentioned previously, joe clark’s excellent book on web accessibility, and many other authorities — some, like jim thatcher, have tallied more years working in the field than most authors and spec writers have been alive (apologies, jim, i’m not calling you old, just giving due and proper respect to your long years of toil)

    the same holds true for the Authoring Tool Accessibility Guidelines (which not only cover how a conforming authoring tool can produce semantically sensible, structured, interoperable, and accessible markup and how authoring tool manufacturers can make their tools accessible to users with “disabilities”), the User Agent Accessibility Guidelines, the highly praised EARL: Evaluation and Repair Language, which has been used to test, amongst other things, GRDDL implementations, and — of course — the WAI-ARIA work which is already beeing implemented into products such as the dojo toolkit, FireFox, and other “mainstream” applications.

    the guidance has been there, but there has been an astounding failure on the part of authors and developers (both of authoring tools and user agents) to treat WAI-generated Technical Recommendations as they deserve, in light of what they are — Technical Recommendations, full stop. as such, they are as binding on other W3C work as any other Technical Recommendation, and form dependencies upon which all other W3C Technical Recommendations are obliged to draw.

    authors, developers, and anyone else involved in the production of web content have had the guidance they need — they just haven’t bothered to avail themselves of it. HTML5 development should be working hand-in-hand with the authors of the emerging WCAG2 specification, for both could learn much from the other.

    ignorance of the law is no excuse — in this case the law is lex parsimoniae, or the “law of succinctness”:

    entia non sunt multiplicanda praeter necessitatem.
    (entities should not be multiplied beyond necessity.)

    citing ALT text as a case of code-bloat — as has been argued by WHAT WG members — is ridiculous, what with the size of the HTML5 draft and the introduction of the VIDEO, PICTURE, FIGURE, and other elements which all could be subsumed by a very tight definition of OBJECT and clear, strong user agent compatibility conformance standards; don’t complain to me if your browser “breaks” OBJECT — complain to those who broke it, and failing that, approach their W3C Advisory Committee member and formally request that they fix their OBJECT implementation.

    this is part and parcel of the fallacious “pave the cowpaths” arguement — bad practices and proprietary hacks should not form the basis of a Technical Recommendation. besides, cattle are notoriously bad navigators, known to go far out of the way when encountering an obstacle — for example, it is not uncommon for “free range” cattle ranchers to surround their territory not with fences and barbed wire, but by simply digging a steep trench, deeper than a cow is tall, to keep the cattle “penned in” without an actual “pen”

    what’s more, cattle are subject to the “herd mentality” (the most obvious manifestation of which is the stampede) which any standard setting organization should strongly discourage…

    what is needed is not a principle of “pave the cowpaths”, but the principle “apply ockham’s razor” — don’t follow the meanderings of the herd, when a more direct solution is superior.

  10. It seems perverse to suggest that poor application development is a good reason to remove the requirement for alternative text. Assistive devices have no programmatic way of knowing when an image is already represented in text. Therefore they (rightly) will announce “image” and / or the filename: Not a great user experience, especially for those users who are then asked to take on trust that the image content is not of value to them.

    Surely a more rationale approach is to put all users before devices or applications. Application developers should prompt users to add valuable alternative text and help them to do so. It is a mistake to automatically generate alternative text as a substitute; it is not a mistake to require it in the specification.

    Removing the requirement for alternative text would not improve user experience, nor help educate developers and users. We should be encouraging everyone to remove presentational images from markup and write valuable alttext, not removing the requirement for it in the first place.

  11. simply boiling the issue down to image having or not having an alt attribute doesn’t cater for the third scenario: an image that is indeed a critical part of the content, but for which the author – through negligence, ignorance, or non ATAG-compliant authoring environments – has not provided an alternative. being able to distinguish between images that are simply iconic/representative of surrounding text and those that have not been authored correctly is essential for signalling to assistive technology whether or not it should attempt heuristics (reading filename, for instance) or alert the user (by simply announcing “image”) in the latter case.

  12. Well, I have not technically a member of the WHATWG or the W3C HTML Working Group, but I have read HTML 5, WCAG 2.0, and the Techniques for WCAG 2.0 specifications.

    Number of examples of alt attributes in img elements in “Techniques for WCAG 2.0”: 1, 2, 3. Oops, that last one doesn’t even have an example.

    Number of examples of alt attributes in img elements in “HTML 5 Working Draft 24 August 2007”: 16.

    Who are these so-called “experts”, and where have they been documenting their knowledge? Oh right, they haven’t; they’re too busy complaining.

  13. mark, check out the CSS2 Technical Recommendation — there are not only 46 instances of ALT text, but also 46 long descriptions (LONGDESC)

    i have a counter question for you, mark — how many of these so called “experts” who are calling for the deprecation of ALT as a required attribute have ever used their computer — much less the web — without either a mouse or monitor? do so, and you’ll quickly find out the value of ALT, as well as the ignorance and indifference of those calling for its formal suppression in specific cases…

  14. There is no section in CSS on how to use alt. From which document are you getting 46 instances of alt text?

    But that doesn’t matter, because nobody should be looking in the CSS specification for something specified by HTML. And the HTML specifications have been inadequate. Nobody has linked to WCAG or WAI from that section, and no authors can be expected to go searching for two indecipherable acronyms in the alphabet ocean that is the W3C.

    I’m late to the party here, but has there been any discussion of linking, from appropriate context in the HTML5 specification, to the appropriate parts of the accessibility recommendations? This would allow authors to discover these recommendations for the first time.

  15. Mark said:
    “Who are these so-called “experts”, and where have they been documenting their knowledge? Oh right, they haven’t; they’re too busy complaining.”

    Mark, here is a long list of links to alt text resources.

    This list includes links to resources by at least 2 of the people you refer to as “so-called experts who are to busy complaining”. the list of resources itself is complied by another of that lot.

  16. charlie, you missed the point entirely — the point of pointing you and others to the CSS2 recommendation is that it is a WCAG 1.0 conformant document, in that 46 illustrations are not only alt texted, but long descriptions are also provided for each of those 46 illustrations… without the ALT text and accompanying long descriptions, there would be large perceptual black holes in the specification; with them, even a blind webmaster can, as dave raggett likes to say, “add a splash of style” to their web sites, and no, not all blind webmasters administer blindness-oriented sites — my first professional gig as a blind webmaster was to construct a campus-wide information system (an intranet, basically) and a public web presence for a college, and i can assure you that the art department wasn’t shy about providing digital images for both, which i duly alt-texted, and — when i thought necessary — encased the image in a link pointing to a long description of the digital image (this was in the days of “wilbur”, a.k.a. HTML 3.2…

    ALT is about preventing perceptual black holes, and providing an equivalent user experience for anyone, anywhere who for whatever reason — physical, financial, or philosophical — either prefers to use a text-based browser or has no choice but to use a text-based browser, as well as those for whom the bandwith isn’t as wide nor nearly as cheap as it is to those indulging themselves with YouTube or any of the other high-bandwith uses/abuses on the web…

  18. mark, as venerable as your “dive into accessibility” resource is…what’s the relevance to this discussion, other than implying that you’re so much more of an expert than other people here? should i go an get a ruler so we can compare sizes, next?

  19. Mark, I have to side with patrick here. Where *HAVE* you been to date? As a “recognized expert” is there a particular reason why *you* might not have assisted WCAG 2 to provide appropriate examples? It’s easy to toss rocks from the outside, but if there are current holes in our own house, we have a joint (professional) responsibility to clean them up.

    As a matter of public question: have *you* been consulted by any members of the HTML5 WG regarding any of their newly proposed accessibility considerations? Before publicly floating the idea of noalt and making alternative text optional, Lachlan Hunt wrote in this blog entry that “specification of the alt attribute was recently worked on” and I’ve already asked who they consulted for guidance regarding accessibility considerations.

    Where you one?

  20. @Patrick: the point is that I know more about accessibility than the average bear, and I don’t feel the need to prove my credentials to random strangers on the Internet.

    @John: while WCAG 2 was being drafted, I was employed by IBM (as an accessibility architect) and was tasked elsewhere. Our team at IBM had several capable representatives working on WCAG, but I was not one of them. I was briefed on its progress weekly for several years, and I read it in full when it was finally published. I have also read all of Joe Clark’s articles and findings about what he perceives as fatal deficiencies in both the WCAG 2 process and the final published result.

    I now work at Google, as does Ian Hickson. We do not “officially” work together, but I have had several discussions with him about HTML 5 in general and at least one discussion about accessibility in particular. My advice to him was to give up and just keep the damn headers attribute, despite the fact that no one could come up with a convincing use case, because I felt it wasn’t a battle worth winning and it might pacify the accessibility community. I did not come away with the impression that he agreed with my logic.

    For the record, I wholeheartedly support the HTML 5 project and this decision in particular. People who truly care about accessibility will do alternate text properly (or at least try), no matter what the spec says. People who do not care about accessibility will not do alternate text properly, no matter what the spec says. In between, we have a real, demonstrated problem of software vendors who favor validation over accessibility to the point of actively hurting the latter to satisfy the former. If you don’t like this particular solution, perhaps you could work on a way to address the underlying problem instead of yelling OMG THEY HATE US over and over.

  21. no one is shouting “they hate us” other than those who are committed HTML5 as it was submitted to the W3C, unreviewed, unfinished and unrevised… just read the blogs or IRC logs at whatwg.org or the listmail of whatwg members on [email protected] — oh, that’s right — you don’t have the time — you’re a professional expert on other peoples problems — you only have time to indulge in ad hominem attacks on persons you’ve never met and whose work you’ve never evaluated… just the fact that you have to flaunt your credentials smacks of the “some of my best friends are…” alibi… no one is arguing that everyone everywhere will write meaningful alt text for every image on the internet; what we are arguing is that if you don’t, your pages won’t validate, nor will they conform to WCAG or any other “web accessibility” guidelines… and if your authoring tool or portal interface doesn’t prompt you for alt text, or doesn’t even have the facillity for entering alternative text, then everybody’s at the mercy of the tool’s limitations, just as most authors are at the mercy of non-ATAG-compliant tools, and non-UAAG-compliant browsers… if you’re really concerned about accessibility, don’t give me your resumé, give me results — or shouldn’t your captive customers dare look behind the curtain, oh, great and powerful “accessibility architect”?

    and, if this blog was intended to shed more light than heat, it would offer a “preview” option so that people don’t shoot from the hip — or, in mark’s case, his wazoo — at each other, without first reading what it is they’ve typed outside the confines of a textarea…

  22. For the record, I wholeheartedly support the HTML 5 project and this decision in particular. People who truly care about accessibility will do alternate text properly (or at least try), no matter what the spec says.

    If you don’t like this particular solution, perhaps you could work on a way to address the underlying problem instead of yelling OMG THEY HATE US over and over.

    Mark,
    For what it’s worth, I see HTML 5 as a great opportunity to improve online accessibility as well, and if the working group can suggest a better way forward, and it is demonstrated that it *is* a better way, then I too will not only applaud the initiative, but get out and actively support it.

    The bigger issue is that there is little discussion about any of these additions or deletions until one of a very small group of developers come out and start talking like it’s in the bag. Accepting poor author habits is one thing, sanctioning them is a completely different thing. The fact that some accessibility experts such as yourself think it is a good step, whilst others (such as Joe, or myself) still have concerns only signals that within the community of “experts” there is still no clear consensus. Yet this lack of agreement doesn’t seem to keep the editors back from making statements such as those coming forward. To make sweeping statements like this is not only irresponsible, it borders on unethical.

    As well, were are the test cases and related results that show this to be the best way? The editors have consistently demanded reams of “proof” from other accessibility figures whenever someone has asked for or questioned any of the other ideas being discussed – however when the tables are turned, they remain remarkably silent.

    And so I posed the question (3 times now): who did they actively seek consultation from before proposing this new way forward? If you were asked specifically about this prior to Lachlan’s “pronouncement” above, say so: if you were not, then please also admit to that as well.

  23. [spacer.gif][spacer.gif][spacer.gif][spacer.gif][spacer.gif][spacer.gif][spacer.gif]

    I think this is a great idea.

    [spacer.gif][spacer.gif][spacer.gif][spacer.gif][spacer.gif][spacer.gif][spacer.gif]

  24. John, I’m not going to indulge you in your ongoing paranoid delusions about a secret HTML 5 cabal. That’s the kind of unconstructive talk that got you banned from the technical mailing list, and rightly so. If you continue to demand unreasonable things, people will continue to ignore you. If you start making valuable contributions (like, for example, pointing to some definitive examples/tutorials of good alt usage — I couldn’t find more than 2 examples in all of WCAG 2) then people are much more likely to take you seriously.

  25. I’ve heard:

    * validators are an important educational tool, and validity is a good stick to force people to address these kinds of issues (I’m overjoyed to hear that validation is now standard…)

    * people who need to shut up validators do so by supplying useless ALT attributes.

    Isn’t the solution, therefore, to give the people an explicit and documented way to shut up the validator?

    One could imagine a variety of solutions like a NOALT attribute or a #NONE attribute value, but it seems clear that using an empty alt attribute is the simplest mechanism. The argument is presented that this cannot be mandatory because sometimes an application wishes to express the fact that a critical image is missing but there is no alternative text for it. This argument makes no sense to me. If the application *knows* it should provide an ALT tag and *knows* that it does not have a good one, then it should simply express what it knows in the alt attribute. For example:

    [filename:foo23.jpg]

    OR

    [NO DESCRIPTION AVAILABLE]

    OR EVEN

    [IMAGE]

    The application is in a better position to “guess” at a useful representation for the missing image than the user agent, because the application has access to the metadata for the image and can make a best guess at a reasonable (but hopefully not redundant!) name. If there really needs to be a standard value for “I really don’t know anything about this image” then the HTML working group should just define the value. Call it #UNKNOWN or #NODESC or something. It is a step backwards for the group to make the wrong behaviour (typically wrong, in any case) the easiest behaviour.

  26. “should i go an get a ruler so we can compare sizes, next?”

    If you’ve followed Mark “holier than thou” Pilgrim over the years, you know that you don’t need a ruler to compare sizes. He’s always overcompensating for his own shortcomings.

  27. John, the current revision of the alt text requirements were based on a significant amount of relevant feedback sent to the whatwg mailing list over the past 3 years and the reviewing of many articles on the issue, many of which were mentioned in that list of resources that Steve Faulkner provided above.

    Please remember that it is an iterative development process, and that this article was written to explain the current state of the spec. No where in it did I say that this decision was absolutely final, and in fact, I even explicitly mentioned at one point that it is “certainly open to debate if you have further evidence to provide”.

    We’ve described our observations, outlined the problem and explained why we think this solution will address it. If you have constructive feedback about why our solution won’t work or alternative solutions that would work better, you are welcome to provide them. But complaints and attacks are not welcome from anyone.

    Gregory, you’re argument seems to be more concerned about authoring tool requirements to allow users to provide alternate text. While I’m sure everyone agrees with you about that, including myself, even if all authoring tools did provide that ability, we would still be left with the problem of what to do when users still don’t provide it.

    BTW, I once asked which approach is better for the user and why, but never got a response from you.

    Gregory wrote:

    citing ALT text as a case of code-bloat — as has been argued by WHAT WG members — is ridiculous

    If you’re referring to this post by Scott Lewis, you’re absolutely correct. The code bloat argument is indeed ridiculous and no “WHATWG member” that I know of has used it. As far as I know, Scott is not involved with the WHATWG at all. Note that I didn’t even use the code bloat argument in this article.

    Paul Prescod, thanks for providing constructive feedback amongst all this bickering from others. The noalt attribute solution has been considered but, if I recall correctly, it wasn’t chosen because it’s not clear why it’s a better solution. Both noalt and omitting alt result in an inaccessible image and neither would satisfy accessibility requirements. While it may solve the validation issue with regards to accidentally omitting an alt attribute, there’s nothing preventing authoring tools and validators from presenting warnings about missing alt attributes.

  28. mark wrote:
    “I don’t feel the need to prove my credentials to random strangers on the Internet.”

    I missed the part where you were asked to prove your credentials, what you did prove was your selfrighteousness.

    The “accessibility community” is not an animal that can be pacified be being thrown a bone (the headers attribute). From the way you talk about your goolge buddy chats with Ian over the fate of the headers attribute, you appear to suffer under the delusion that Ian Hickson owns HTML 5, I sincerely hope that he does not suffer under the same delsuion.

  29. Lachlan, some comments on the prose in your article:

    The current formulation in the draft describes, as you say, «where the alt attribute may be omitted entirely». But then further down in your article you talk about the «benefit of requiring the alt attribute to be omitted, rather than simply requiring the empty value». Does this mean that you actually want to go further than the current formulation, by defining usecases where it should be an requirement that alt is dropped? Because, as of today, I see no such requirement in the formulations about alt. I see that it says that «If an image is a key part of the content, the alt attribute must not be specified with an empty value.» And this is an very important thing. It should be the first sentence under its section! And not the last, as it is now.

    But you then describe the benefit of omitting alt as «it makes a clear distinction between an image that has no alternate text (such as an iconic or graphical representation of the surrounding text) and an image that is a critical part of the content […]».

    I wonder how many, having read that wording, would grasp that you actually say that the image, if it is a «critical part of the content», should rather have no alt attribute at all, than have an empty alt attribute. This will indeed be difficult for authors: if the image is critical, then provide no alt for it. Would we not all think that our images are critical?

    This make it sound as if we have this value hierachy:

    0 = alt="",
    1 = alt="Normal image",
    2 = critical image, therefore no alt!

    This logic risks, IMHO, causing people to not use alt. After all, why provide ALT text, if I can signfiy great image value by omitting it? Agree about this risk?

    We must also ask: who do we provide this value hierarchy for? If I am using a UA that reads the page for me, then I will probably hear no difference between empty alt and no alt at all? So, for whom do we provde this hierarchy? The author, so he can see what is important or not?

    My take on this would rather be that if there has not been time for authoring an ALT text, and if the image is critical, then e.g. a text like «To be written» or «Not written yet» or simply «Unwritten» – or why not «LONGDESC to be written» – would be more fitting.

    You then say «It has been claimed that Lynx and Opera already use this distinction.» You say «claim». I think there is no doubt about how Opera and Lynx works. It sounds as if you take Opera’s behaviour as an example of an UA that does what the HTML5 paper currently says. But the e-mail by Charles that you link to, says that the “Image” text is an ad-hoc alt-text – a repear of missing content. I do not understand how you can take Opera’s behaviour as proof that it is possible to not have alt. Opera would have to stop showing replacement alt-text if the current paper should be implemented.

    Then you say that «It is still somewhat questionable whether this distinction is actually useful». The distinction between what? The usefulness for what? Is it the Opera/Lynx behaviour you questions? Or the usefullnes of the distinction between alt an noalt? Well, I certainly agree that the latter is questionable. You have identified a usecase – critical images « that doesn’t have an obvious textual alternative». But you have, as I think you are open to consider, not really documented that we need any special way to treat this usecase. Rather, it seems to me as if the general rule of providing an alt text is the more important in this case. So I am doubtful about whether the current text can stand the test of time.

    I hope you found these comments constructive.

  30. Leif, I think you have misunderstood the issue. For images that are a critical part of the content, good quality alt text absolutely should be provided by the author. However, in reality, good quality alt text is not always available and and we need to define what authoring tools should do in that case. In such cases, omitting the alt attribute is preferred over inserting an empty value or generating it poorly from the image metadata.

    Think of it like this: Authoring tools should ask the user for alt text. If the user provided it, use it. Otherwise, omit the alt attribute entirely.

    I was referring to the distinction between the meaning of alt="" and no alt attribute, and whether or not that distinction is useful to the user. I said it was questionable because some have claimed that something like alt="unknown" would be preferable to omitting alt. My feeling is that omitting it and letting the user agents repair the missing content (as described in UAAG) is better for the user than using a meaningless or empty value. I would certainly be interested in any evidence for this issue either way, and in fact I have asked for it before.

  31. @Mark,

    > the point is that I know more about accessibility than the average bear, and I don’t feel the need to prove my credentials to random strangers on the Internet.

    No, the point is that you used your credentials to call somebody names, so don’t whine about somebody asking why your credentials are important. You brought them into the argument, nobody else did. If you disagree with Gregory, then explain why you disagree with him, don’t just say “I’m an expert and you’re stupid, so shut up”.

  32. I do not agree, that no alt text is better than bad (not appropriate) alt text. Correct would be, that an empty (null) alt text would be better. This is indeed an accessibility aspect. If rendered in a non-grafical context there is a placeholder for raster grafics. If there is no alt text, the placeholder is the file name, which in most cases is a bad placeholder. If no alt text is available then the placeholder should be an empty text, provided with an empty alt attribute.
    It is a fact that many (or nearly all) users of picture webspaces like flickr don’t provide useful alt texts. But these providers do not enhance that by putting in crappy alt texts. If there is no alt-text provided by the user it would be best to put in an empty alt text.
    Crappy behaviour or implementations are no argument to standardize that 🙂

  34. Lachlan,

    As I said above, this model requires a choice between alt=””, alt=”text” and zero-alt. Still, your description of how the authoring tool should work mentions only one ALT promt: «… ask … for alt text. If … provided … use it. Otherwise, omit … alt … entirely.» Where is the step where the authoring tool asks the author to choose between alt=”” and “omit alt”?

    This author tool behaviour is more likely: First, it asks «Do you want the ALT attribute at all?» If no, then «omit the alt attribute entirely». If yes, then go to promt number 2: «… ask … for alt text. If … provided … use it. Otherwise,» … insert empty alt=””. So unless you know a better behaviour, then this ALT model will cause many to opt for the no-alt solution. And the tool could not have asked «do you have alt text ‹available›?» Because, what if the alt had to be empty? The author would then quite likely answer no – and we would get a no-alt for things which should have alt=””.

    I understand the central point in your last paragraph to be the question whether «alt=”unknown” would be preferable to omitting alt». You find «omitting it and letting the user agents repair the missing content» have most sense (while Charles, in the e-mail you pointed to about «repair content», speaks against this authoring praxis).

    But if the spec says that you must not use ALT at if you can’t provide proper alt text, then what is there to repair? It cannot be the right thing to count on the UAs to repair the content. But if one agrees that is the right way to author anyhow, then it must be mentioned in the authoring requirements – and in HTML5 at all («well defined behaviour» for repair content should be specified!) An author needs to be able to make such decisions! For instance, which language should such repair content be? Opera presents localized repair content – that is, localized according to the language of the UA. But as many tools are only available in english … ?

    And Asbjørn Ulsberg, allthough he appears to think otherwise, is not in tune with your thoughts about «repairing content» when he says that «no alt text is better than poor alt text». He would have been in tune if he said that «repair text is better than poor alt text». I think the focus on «poor quality as worse than nothing» shows some misconseption about ALT. And actually, if you think «repair alt» is better than «poor alt text» – then you must think that «poor» is very poor! 😉 Well – actually, I think that Opera’s repair content for the IMG element is better than alt=”unknown”. (Currently it uses just a (lcalisation of) «Image».)

    What is lacking here is good advice about how to write meaningful alt texts when you have 3000 images to upload. It seems overboard to require «quality text» for 3000 images. Author tools should offer ways to enumerate series of images – and present the enumeration as alt text. If you have 10 images of mother and father last summer, then «mother + father last summer 1», «mother + father last summer 2» etc. I don’t know, but I think that this is what Gregory have in mind in his comment when he talks about using the computer «without either a mouse or monitor? do so, and you’ll quickly find out the value of ALT».

    We, sighted users, think of ALT texts only as something that steps in and magically turns the page in to master novel as soon as the URI is wrong or the image resource is unavailable. But, for an unsighted user, the alt-text also for pure practicality – as referenes and for downloding/sending links (and when it is just for practical reference, then it should not be artsy).

    Finally I’d like to ask: Sighted users – and authors – enjoy tooltips. Therefore, authors put TITLE on images. But arent many of those titles rather ALT texts in their form? The line betwen description (as a TITLE can be) and replacment content (as ALT is supposed to be) is super-thin. Look at the section about «A phrase or paragraph with an alternative graphical representation». First: if the graphical representation is an alternative to the text, then then text should not be alterted to fit the graphic! It should be the other way around! Second, in the examples of good and bad practise, the difference between the good and the bad is simply that of the definite «the» and indefinite article «a»! However, I were the author, I would have preferred the indefinite article! (Further more: many none-english/non-germanic readers doesn’t have a clue about the diff between definite/indefinite article.)

    It is strange that TITLE and the problems with ALT versus TITLE aren’t mentioned yet in the spec proposal. It is also interesting that TITLE isn’t required. But ALT is. Yet, we are bashing Microsoft/Internet Explorer for showing ALT as tool tip … Stay tuned!

  35. Leif, there’s nothing preventing the UA from using the TITLE as part of its presentation of alt text. For an image without an alt attribute, a visual browser with images turned off may want to keep the title in the tooltip, but a voice browser could, for example, present the image as “Image with title [insert title here] *ding*”. Even sites like Flickr can easily add the ‘title’ attribute, since Flickr at least already has a visible title field that many people do use.

    An editor UI for inserting alt content could be, for example, a button that says “Add Text Alternative for Visually Impaired” or something else that encourages the author to consider blind people’s needs, and that presents a text field and an explanation of how to choose good alt text when pushed. If it’s not pushed, no alt attribute is generated and the browser UA (NOT the editor UA) can do its best to generate something useful for its users. If it is pushed and left blank, then alt=”” is generated. (Although other people might use alt text, I think explicit text like this would be more likely to resonate with the author, since it reminds them that a) this is important for accessibility and b) they should be considerate of any blind people who have to use the page.)

    What the spec could do to improve the presentation of and navigation through images for which no alt text is available or appropriate, is to encourage or rather RECOMMEND use of the ‘title’ attribute. This is something authors should have less trouble getting right, that can be provided for any image that truly belongs in the content, and that gives the UA (and thus hopefully also the reader) more information to work with when presented with images that have no alt text.

    An HTML5 conformance checker can then output warnings for images that have neither alt nor title text. This would be much less likely to backfire and cause authors to add inappropriate alt or title text, because title text is pretty easy to get right and it’ll nonetheless remove the warning from the validator output.

  36. Fantasai, you say one could have a button «Add Text Alternative for Visually Impaired». And then you say: «If it is pushed and left blank, then alt=”” »

    So who, when seeing the button «Add Text Alternative for Visually Impaired», will press it in order to add a alt=””?

  38. The ATAG link: «The authoring tool must allow the author to accept, modify, or reject equivalent alternatives.»

    «Reject» currently (HTML 4) means just one thing: ALT=””.

    It really would be interesting to hear if ATAG thinks it is possible to implement two different and semantically opposed kinds of «reject».

  39. currently I am writing from a mobile phone and for mobile devices the alt-attribute is more than essential.
    the only problem is when alt-attributes are with every single image, not only with images with relevant content as it should be.

  40. I do not consider myself to be an expert in accessibility, but I have always done my best to make sure sites I build are as accessible as possible. With that in mind, I would like to offer a “non-expert” point of view about the use of alt attributes.

    I’m very uncomfortable with the notion that alt attributes could be omitted on normal images simply because (a) authors are unable to define them due to using some sort of content management system that ignores them, or (b) authors choose not to define them for reasons of ignorance or laziness.

    I do not like the current system of using an empty alt attribute on images that are purely decorative either. Since such images offer no semantic value, I do not believe they should exist in document markup at all. I prefer to use CSS to add such images.

    I continue to believe that alt attributes should be required. I would prefer to see an empty alt attribute produce a validation warning, and a missing alt attribute produce a validation failure. This would put pressure on the authors of CMS software and web developers to use the attributes correctly, and hopefully encourage authors to use CSS for decorative images instead of littering their markup with them.

    In summary, I think the suggestion of allowing (or requiring) the omission of the alt attribute is a Bad Thing. We should not be making it easy for CMS authors or web developers to be lazy. A CMS can offer a user an example of sensible alt text or fall back on some sort of omission keyword (like “image”).

  41. As I explained in the article, we’re trying to address the problem of crappy tools generating poor quality alt text, which is considered worse than providing no alt text at all.

    But you’re not solving anything! It is well document that alt=”” is a perfectly valid construction. If the people behing Flickr, Wikipedia et al don’t have the wit to figure out that if they can’t get hold of decent alt text for whatever reason, they should put an empty alt, they’re unlikely to notice that they can leave the alt off altogether.

    The solution you’re looking for is to go round to every idiot web design and give them a good dose of clue-by-four, but that’s going to be a very time-consuming project.

    Allowing people to omit the alt attribute altogether will not help anything, other than reducing some documents by 7 bytes per inline image. There is still no way to tell whether the alt attribute has been left off deliberately because there is no appropriate alt text, or whether it has been missed because the author or authoring software is deficient in clue. Changing things for the sake of it won’t achieve anything other than confusion.

  42. It seems that the omission of the alt tag can mean two things:

    1) the image is “a key part of the content that doesn’t have an obvious textual alternative”

    2) the developer/designer doesn’t know what they are doing

    Could you add a noalt attribute, indicating (1)? Then validators should throw errors when neither an alt or noalt attribute is specified – ie – (2).

  43. you should keep two important notes about the alt- attribute:
    1. The alt- attribute is not a tooltip

    2. The alt- attribute is a part of the content. If an image contains content, the img-tag is not enough to describe it. You could use the title- or longdesc-attribut, but they are not a part of the content.
    Most of the images are not a part of the document’s content. many alt- attributes are filled with texts like “click here”, the images’ filename or a description of the image like “picture of a bike”. In most cases the information that is stored within the alt-attribues is completely usless. This lcould lead to the conclusion that the alt-attribute may be omitted. but this conclusion is wrong.

    somebody may use a screenreader. the screenreader tells that there is a image. The user needs the information if the image has got relevant content (maybe a chart with voting results) or just a simple decoration image. So if the image is not a part of the content there must be an empty alt-attribute.

    With a CMS that is flexible enough you should customize it to add an empty alt-attribute to every image on your website. for the few images that are a part of the content (if there are any) you can manually fill the attribute.

    with this strategy you won’t ever think about omitting the alt-attribute because it enrichens your content.

  44. Are auto-generate alts really a problem ? You talk Flickr and Photobucket. I don’t know any blind people visiting these websites.
    Don’t blind people know when they are on a website where they should ignore alt attributes ?

  45. You will be doing us all a great favor by requiring alternate text.

    Here’s why:
    All anyone will hear when you make the alt attribute optional is that it is optional. They will not read anything else about it. Case closed, the end. Optional will equal “don’t need it.” Optional will be the operative word. The law of conservation of Web production energy will _demand_ an end to the entire practice of adding alt attributes. After all… it’s optional, not needed, no longer in fashion, out of sight out of mind… so 2007. Practically deprecated. Believe me, you can write anything you want, bushels of words, reams of text, but all anyone will get out of it is that the alt attribute is no longer needed.

    If, however, you make it part of the specifications that alt attributes are required you are sending the message that they are important. That they mean something to users of assistive technology. That they mean something to people who have graphics turned off for whatever reason, that they convey some meaning to someone, somewhere, and that they are required because they make the Web come alive with meaning that is lacking without them.

    Optional = not needed.

    Required = required.

    My Web environment has thousands and thousands of pages. In a three level scan we find just under five thousand pages. Eighty percent of the images on those pages have no alt attributes. That’s eighty percent of thousands of images that convey no meaning whatsoever to people who rely on them. That’s with the alt attribute required. That’s with a dedicated effort underway to get people to write meaningful alt attributes. Imagine what it would be like if it were optional!

    Please re-think this decision, it’s not too late, there are millions of users depending on alt attributes, think of them when you make your final recommendation.