Summary

The img element in the current HTML 5 draft doesn't include the longdesc attribute, and the alt attribute will no longer be a required attribute.

Author: Gez Lemon

Contents

The longdesc Attribute

One of the great things about the current HTML 5 draft is that they give plenty of examples of how to specify alternate text for images, although a few of them are misguided. Alternate text should be concise, and a longer description provided with a longdesc attribute if necessary. The incomplete techniques document for the current WCAG 2.0 draft contains the following advice for specifying alternate text on images:

When using the img element, specify a short text alternative with the alt attribute. Note. The value of this attribute is referred to as "alt text".

When an image contains words that are important to understanding the content, the alt text should include those words. This will allow the alt text to play the same function on the page as the image. Note that it does not necessarily describe the visual characteristics of the image itself but must convey the same meaning as the image. If the text in the image is more than can fit in a short text alternative then it should be described in the short text alternative and a longdesc should be provided as well with the complete text.

As the current specification for the img element in HTML 5 doesn't include a longdesc attribute, the alternate text in their very first example is too verbose at 43 words (216 characters). The example would be better if the image was described more succinctly, and the extra information included in the main body text; if text in the main body is undesirable, because it's duplicating the content in the image, for example, then a better technique would be to specify a URI to a longer description using the longdesc attribute. If the final HTML 5 specification doesn't include a longdesc attribute, then authors of accessible material will have to resort to the infamous D-link, deprecated in WCAG 1.0 techniques in favour of the longdesc attribute.

As the longdesc attribute's value is a URI, the resulting page containing the longer description can be marked up with rich structural elements (lists, tables, and so on) to aid understanding, which isn't possible with plain text in an image's alt attribute. The longdesc attribute is useful for creating accessible content without having to resort to D-links, which can detract from the design of a page.

[Back to the contents]

The alt Attribute

Another contentious issue with the current HTML 5 draft is that the alt attribute for an image may be omitted completely. The reasoning is along the lines that there are examples of applications where users don't know how to provide alternate text, such as Flickr, and it has been observed that systems make up for this by generating alternate text from the image's meta data. The perceived benefit of not providing alternate text supposedly makes it easier to distinguish between images that have no alternate text, or are part of the critical content. From an article by Lachlan Hunt about why the alt attribute may be omitted:

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 [sic] alt text is available.

I don't understand how a user agent is supposed to differentiate between an image with deliberately missing alternate text, or alternate text that is missing because the author didn't know how to specify alternate text. We all agree that alternate text is essential for accessibility; it's not accidental that the very first requirement from any set of accessibility guidelines is that alternate text is provided for non-text objects.

Providing blank alternate text is something that must be done deliberately, and helps user agents determine whether or not the alternate text is in need of repair, as opposed to just omitting the attribute; of course, there will be scenarios whereby assistive technology will rely on heuristics when alternate text is missing, regardless of the markup - for example, when an image alone is used as the link phrase in an anchor element or part of an image map and empty alternate text is provided. In this case, assistive technology has to present something to the user so that they know what the link is, so will attempt to get the information elsewhere; such as from the title attribute, or in extreme cases, from the src attribute of the image. At least specifying null text for the alt attribute is a definite decision on the part of the author, and not the ambiguous situation of not knowing whether the alternate text was accidentally or intentionally omitted.

Alternate text contains important information about an image that must be included in the structure, even if that information is blank because the image is purely decorative. It is better that purely decorative images are not included in the structure in the first place, but included with CSS. However, there should also be a markup solution to indicate whether or not the alternate text of an image is critical to understand the content - omitting such an important attribute is ambiguous, and doesn't help anyone. Systems that generate poor quality alternate text need fixing, and all authors should be encouraged to provide high quality alternate text.

[Back to the contents]

Further Reading

Translations

Category: Accessibility.

Comments

  1. [html5-image-element-no-alt.php#comment1]

    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 [sic] alt text is available.

    I thought I read this wrong, but it really does appear to be stupid. How is making the two options the same making them clearly distinctive?

    If this article is any indication of the changes coming in the HTML 5 specification, I suspect it'll be another XHTML. HTML 5 should be an improvement on HTML 4, not another backwards step.

    Posted by Danny Tuppeny on

  2. [html5-image-element-no-alt.php#comment2]

    Right. Here's how I see it.

    I think there are three situations with HTML images (I may be missing some):

    1. Image is decorative.

    2. Image is meaningful, and we have appropriate text.

    3. Image is meaningful, but we haven't got appropriate text.

    4. We haven't thought about whether the image is meaningful or not.

    Everyone seems happy that the correct approach for situation 1 is an empty alt attribute. Situation 2 is hopefully obvious.

    The proposed HTML 5 approach to situation 3 (omit the alt attribute altogether) seems to offer a way for us to distinguish it from 1 and 2 in a machine-readable way, and lets us off the validation error we would have got under previous versions.

    It's also what probably happens most of the time in situation 4 (although I don't have any stats to back that up).

    If distinguishing this situation isn't actually useful (it doesn't, after all, tell users what the image means), or if we think authors should get a validation error for breaking this accessibility guideline, then the proposed HTML 5 approach is no good.

    I'm not sure on either count.

    Posted by pauldwaite on

  3. [html5-image-element-no-alt.php#comment3]

    I may have misunderstood the text I quoted. I read it as "an empty alt attribute is illegal", but now I'm not so sure.

    My opinion is that an empty alt attribute should be used for decorative images, and an omitted alt attribute is for a non-decorative image that has no alt text.

    This would allow an author to quickly find images he's missed alt attributes on (finding all attributes with no alt attributes) while excluding known decorative images (which have empty alt attributes).

    At the same time, this would enable screenreaders to silently skip decorative images but announce the presence of important images that simply have no description.

    It this is what the HTML 5 spec means (and I originally misunderstood), great. If it's saying we should omit alt attributes for both decorative images AND those with no description, then I think it's a mistake.

    Posted by Danny Tuppeny on

  4. [html5-image-element-no-alt.php#comment4]

    Thank you for your comment, Paul.

    The proposed HTML 5 approach to situation 3 (omit the alt attribute altogether) seems to offer a way for us to distinguish it from 1 [image is decorative] and 2 [Image is meaningful, but we haven't got appropriate text] in a machine-readable way, and lets us off the validation error we would have got under previous versions.

    The problem is that the proposed approach by the HTML Working Group assumes that the alt attribute has been deliberately omitted, which makes it impossible to distinguish between this scenario, and alternate text that has been omitted through ignorance or through a poor authoring tool. The approach suggested by the HTML working group doesn't offer any real improvement over the current situation. Poor alternate text is something we do desperately want to avoid, and I'm encouraged that this is something that the working group have investigated. Unfortunately, this particular proposal won't make the situation better. The real answer lies in tools that adhere to the Authoring Tool Accessibility Guidelines (ATAG), and educating users at all levels (professionals, and casual users of web services, such as Flickr).

    Posted by Gez on

  5. [html5-image-element-no-alt.php#comment5]

    Hi Danny,

    I may have misunderstood the text I quoted. I read it as "an empty alt attribute is illegal", but now I'm not so sure.

    The HTML 5.0 working group don't have a problem with empty alternate text: 

    <img src="decoration.gif" alt="">

    They're suggesting that not providing an alt attribute at all is acceptable, as tools that automatically generate alternate text for conformance reasons often make accessibility worse. Their assumption is often true, but rather than tackle the problem with the tool vendors, they're suggesting the problem can be solved by not making the alt attribute a required attribute (therefore, services won't attempt to generate the alternate text automatically to adhere to the specification), which then means the user agent should use repair techniques to fix the missing attribute. The problem, of course, is determining whether the alternate text has been intentionally omitted, or omitted through ignorance or because of a poor authoring tool.

    Posted by Gez on

  6. [html5-image-element-no-alt.php#comment6]

    the proposed approach by the HTML Working Group assumes that the alt attribute has been deliberately omitted, which makes it impossible to distinguish between this scenario, and alternate text that has been omitted through ignorance or through a poor authoring tool

    Very true. I'm not experienced enough with screen readers to know which distinctions are more helpful, if any.

    And you're quite right: getting more good alt text is what we actually want. That's just not a problem that a mark-up language specification can help with much.

    Posted by pauldwaite on

  7. [html5-image-element-no-alt.php#comment7]

    That's just not a problem that a mark-up language specification can help with much.

    Making the alt attribute a required attribute will help; but we also need to get software vendors to follow ATAG, and not just by paying lip-service by generating poor alternate text. I can't stress enough how impressed I am that the HTML 5 working group have attempted to address this issue, but in this particular instance, I think they've arrived at the wrong conclusion.

    Posted by Gez on

  8. [html5-image-element-no-alt.php#comment8]

    I checked the blog post on whatwg blog and I really like this comment made by Mark:

    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.

    - this is really great comment for the HTML 5 issues!

    Posted by Tomasz Gorski on

  9. [html5-image-element-no-alt.php#comment9]

    I checked the blog post on whatwg blog and I really like this comment made by Mark:

    I too was overjoyed to see that he who knows more about accessibility than the average bear had commented about accessibility's number 1 issue - alternate text. Although, I must admit to being a little surprised that he favoured encouraging authoring tool vendors to drop alternate text, as opposed to encouraging authoring tool vendors to make it easier for their users to provide alternate text.

    Posted by Gez on

  10. [html5-image-element-no-alt.php#comment10]

    As the current specification for the img element in HTML 5 doesn't include a longdesc attribute, the alternate text in their very first example is too verbose at 43 words (216 characters).

    Some pictures are worth a thousand words. Why is 43 too many?

    The example would be better if the image was described more succinctly, and the extra information included in the main body text; if text in the main body is undesirable, because it's duplicating the content in the image, for example, then a better technique would be to specify a URI to a longer description using the longdesc attribute.

    Why would it be better to use an attribute that authors routinely misuse, that browsers routinely ignore, and that requires an extra page load?

    Posted by mpt on

  11. [html5-image-element-no-alt.php#comment11]

    Some pictures are worth a thousand words. Why is 43 too many?

    Alternate text is supposed to be concise. Lengthy alternate text is difficult for assistive technology users, as they can't control the way it is announced, as they can with body text marked up in semantic elements. The advice for specifying alternate text on images in HTML from the WCAG 2.0 techniques document emphasises the point that alternate text should be short, and that longer descriptions should be provided using the longdesc attribute. If a picture is worth a thousand words, those words should have a good semantic structure.

    Why would it be better to use an attribute that authors routinely misuse, that browsers routinely ignore, and that requires an extra page load?

    This is the crux of the issue - if something is not used correctly that aids accessibility, the answer isn't to drop the feature. The answer is to encourage tool vendors to make it easier for those features to be used, and educate users to want to use those features. It is difficult to describe complex images with flat text in an alt attribute. The longdesc attribute provides a way that enables screen reader users who are totally blind to have equivalent access to content. That is why it is better to keep the longdesc attribute.

    Posted by Gez on

  12. [html5-image-element-no-alt.php#comment12]

    I agree that alt= text being unable to contain markup is a problem. If that is important for a particular image, I suggest using <object> -- which, while not supported perfectly in Web browsers, is supported much better than longdesc= ever has been or will be.

    The WCAG 2.0 Techniques document is, as demonstrated by its "Resources" sections, written with HTML 4 in mind. Much of it may still be applicable to HTML 5, but it seems the section on alt= text is one that is not. It certainly doesn't make sense to use the WCAG's advice for HTML 4 authoring as an argument against what the HTML 5 specification says.

    You say "the answer isn't to drop [the longdesc= attribute, but] to encourage tool vendors to make it easier for those features to be used, and educate users to want to use those features". But accessibility advocates and browser and authoring tool developers have now had ten years in which to encourage good use of longdesc=, and they have failed spectacularly. It's time to try something else.

    Posted by mpt on

  13. [html5-image-element-no-alt.php#comment13]

    Hello mpt,

    I agree that alt= text being unable to contain markup is a problem. If that is important for a particular image, I suggest using <object>

    How will that help? The fall-back content for the object element is only used when a user agent is unable to render media in a user agent. If the image is rendered, which it will be in most graphical user agents, the text alternative won't be made available to assistive technology if the object element is used, beyond the mechanisms provided by the main and fallback content itself, such as though the alt and longdesc attributes of the media that is finally rendered by the user agent. The alternate text description is sill required for fall-back mechanisms, such as the img element, and the alternate text for the object element itself should be provided through the title attribute.

    which, while not supported perfectly in Web browsers, is supported much better than longdesc= ever has been or will be.

    That's just not true. The longdesc attribute is conveyed to assistive technology. Assistive technology interprets applications for its users, such as Internet Explorer. If the application cannot relay the information to the screen reader, the screen reader user doesn't get that information. However, assistive technology can and does make use of the longdesc attribute. Pressing the Enter key when the image has focus in JAWS will open the URI defined by the longdesc attribute, and pressing Alt + Enter when the image has focus will open the URI defined by longdesc attribute in Window-Eyes. Home Page Reader and pwWebSpeak have similar function to open URIs pointed to by the longdesc attribute. The attribute is even available from regular browsers such as Firefox, from the Properties menu item from the context menu.

    It certainly doesn't make sense to use the WCAG's advice for HTML 4 authoring as an argument against what the HTML 5 specification says.

    WCAG 2.0 is intended to be technology neutral. The guidance should be applicable to all technologies. Guidance for HTML 4.01 (and XHTML 1.0) should be applicable to any markup language derived from the HyperText Markup Language. It most definitely does make sense to use WCAG 2.0's advice for HTML 5.0, or any other version of HTML.

    You say "the answer isn't to drop [the longdesc= attribute, but] to encourage tool vendors to make it easier for those features to be used, and educate users to want to use those features". But accessibility advocates and browser and authoring tool developers have now had ten years in which to encourage good use of longdesc=, and they have failed spectacularly. It's time to try something else.

    Yes, I do say that the answer is to encourage tool vendors to make it easier to add alternate text and long descriptions to images, and it remains a credible suggestion. Web accessibility advocates cannot be held responsible for authoring tool developers failing spectacularly in providing tools that help authors provide alternate text and providing ways of specifying long descriptions. Accessibility advocates have asked, and continue to ask that authoring tools make it easy for authors to provide this information. If you have a problem with the spectacular failure of authoring tool vendors, maybe you should take the issue up with them, rather than the people trying to make the situation better. Trying making alternate text optional is not a credible suggestion for something as essential to accessibility as alternate text.

    Posted by Gez on

  14. [html5-image-element-no-alt.php#comment14]

    Yes, the longdesc attribute is conveyed to assistive technology. But I specifically mentioned Web browsers, not AT, because it is Web browsers that are the deciding factor here. Since most authors do not use AT, most authors will remember and care to use only those accessibility techniques that also have an obvious effect in their browser(s) of choice. You can see the effect of alt= by turning images off. But no browser developer in the past ten years has come up with an obvious and non-annoying way of presenting longdesc=, and as a result, authors far more often misuse it than use it properly. That is why I don't "have a problem with the spectacular failure of authoring tool vendors" to support it well either: because it's not a viable solution. Time to try something else.

    Meanwhile, you seem to be confusing the WCAG 2.0 Guidelines with the WCAG 2.0 Techniques. The former are indeed technology-neutral. But the latter refer specifically and repeatedly to HTML 4, and are therefore relevant to other versions of HTML only where those versions are the same as HTML 4 (like XHTML 1 is, but XHTML 2 and HTML 5 are not).

    Your claim that "Guidance for HTML 4.01 (and XHTML 1.0) should be applicable to any markup language derived from the HyperText Markup Language" has never been true, ever since HTML 1.0. Guidelines on using alt= in HTML 4 do not apply to HTML 1.0 (which did not have it) and may not apply to HTML 5 (which alters its purpose). Guidelines on using longdesc=, <frame>, <frameset>, or <noframes> in HTML 4 do not apply to HTML 1.0, 2.0, 3.2, or 5 (none of which have them). Guidelines on using <menu> in HTML 4 do not apply to HTML 5 (which uses that element very differently). And so on.

    Posted by mpt on

  15. [html5-image-element-no-alt.php#comment15]

    Hello mpt,

    Yes, the longdesc attribute is conveyed to assistive technology. But I specifically mentioned Web browsers, not AT, because it is Web browsers that are the deciding factor here. Since most authors do not use AT, most authors will remember and care to use only those accessibility techniques that also have an obvious effect in their browser(s) of choice.

    The longdesc attribute is an accessibility feature intended to aid people using assistive technology. This website is mostly concerned with accessibility, which is why I am discussing the impact on accessibility from HTML 5's proposal for the img element. You might not care about assistive technology, but I do.

    Time to try something else.

    Do you have something credible to suggest for moving forwards apart from doing nothing? Dropping accessibility features is not trying something else - it's being apathetic about accessibility.

    Meanwhile, you seem to be confusing the WCAG 2.0 Guidelines with the WCAG 2.0 Techniques

    I haven't confused the two, which is why I specifically mentioned the phrase techniques document on the two occasions that I referred to the advice on using the alt attribute. You are correct in that the advice on using alternate text couldn't be applied to the original version of HTML, although you are being deliberately obtuse. Developers are encouraged to use the latest version of a technology where there is support for that technology, as those technologies are developed with accessibility in mind. When HTML 5 becomes a recommendation in the distant future, HTML 5 will also have been developed with accessibility in mind, which is why those with an interest in accessibility are contributing to discussions about the accessibility provisions of HTML 5.0.

    Posted by Gez on

  16. [html5-image-element-no-alt.php#comment16]

    Do you have something credible to suggest for moving forwards apart from doing nothing?

    Yes.

    1: Drop longdesc= in favor of <object> fallback content in the few cases where markup is important, and <img alt= in the majority of cases where it isn't. Lobby browser vendors to fix the bug you described with <object> fallback content not being exposed to AT. (This is much more credible than expecting most authors to ever get longdesc= right.)

    2: Introduce a new noalt attribute in HTML, such that any <img> element must contain either alt= or noalt. This way authors can use validation to distinguish between images for which they cannot possibly provide useful alt text (e.g. images uploaded by users of their site) and images for which they just forgot to provide alt text (and can therefore fix the problem).

    3: Rewrite the WCAGs so that authors are more likely to read them at all, and the WCAG Techniques so that they apply to HTML 5.

    Posted by mpt on

  17. [html5-image-element-no-alt.php#comment17]

    Hello mpt,

    1: Drop longdesc= in favor of <object> fallback content in the few cases where markup is important, and <img alt= in the majority of cases where it isn't. Lobby browser vendors to fix the bug you described with <object> fallback content not being exposed to AT.

    This isn't a bug. The fallback content for the object should be rendered when the user agent is unable to understand the MIME type of the embedded content. If the user agent understands the MIME type, then it should render the content, and ignore the fallback content. A screen reader interprets applications for its users, so would get the version that the browser was able to render - so could only read the alternate text provided through the title attribute in this case.

    Personally, I prefer the generic object element for embedding media in a document, as opposed to the img element, but I would like to see the longdesc attribute added to this element to provide a mechanism for a longer description.

    (This is much more credible than expecting most authors to ever get longdesc= right.)

    Ignoring the fact that it couldn't work, I don't think it is easier. It's amazingly simple to specify a URI in an attribute value, and stops the page being bloated unnecessarily. Of course, the ultimate fallback content could just be a link to the longer description, but the browser would need to render that link (or the text version of the object), which won't be the case when a graphical user agent renders an image.

    2: Introduce a new noalt attribute in HTML, such that any <img> element must contain either alt= or noalt.

    This is a good idea, and I would support this, as there is no ambiguity. As far as I'm aware, this has already been suggested, but I'm not sure of the working group's stance on this suggestion. I know they're reluctant to add new attributes, but this would be good because it removes any ambiguity.

    3: Rewrite the WCAGs so that authors are more likely to read them at all, and the WCAG Techniques so that they apply to HTML 5.

    The WCAG working group have done an excellent job writing the guidelines so that they're much easier to understand since the last draft. The techniques documents still need a lot of work, but there are a lot of capable people working on them. Because the techniques document isn't normative, techniques for HTML 5 will be added as and when techniques are required that are different from the current HTML techniques.

    Posted by Gez on

  18. [html5-image-element-no-alt.php#comment18]

    Gez, why do you think UAs shouldn't expose the contents of OBJECT to ATs (ignoring for a moment whatever HTML4 says)? If the contents are present in the DOM (which they aren't in IE, sadly), ATs can make use of it if they can't process the embedded content (e.g. if it's an image).

    I don't see why the following snippets should be treated differently: 

    
<img alt="foo" src="test.png">

<object data="test.png">foo</object>

    Surely, insisting that the fallback content of OBJECT musn't be exposed to ATs isn't doing accessibility any favor?

    Posted by zcorpan on

  19. [html5-image-element-no-alt.php#comment19]

    Hi zcorpan,

    Gez, why do you think UAs shouldn't expose the contents of OBJECT to ATs (ignoring for a moment whatever HTML4 says)?

    I can't work out how assistive technology could expose the content without the user agent first rendering the content, as screen readers interpret applications for their users. Suppose you had an arrangement where the primary content was accessible Java, followed by a captioned sound track, followed by an image, followed by HTML content: 

    <object classid="java:Press.class" width="500" height="500">
    <object data="Pressure.mpeg" type="video/mpeg">
        <object data="Pressure.gif" type="image/gif">
            <h2>Title</h2>
            <p>...</p>
        </object>
    </object>
</object>

    Each of the embedded technologies should have their own accessibility features, so whichever is understood by the user agent should be rendered. If the embedded content is also rendered, the renderings would clash. And it doesn't solve the problem of which version the user would prefer to have rendered. A longdesc attribute would at least provide a mechanism to get to a text page for whatever media was rendered by the user agent.

    Surely, insisting that the fallback content of OBJECT musn't be exposed to ATs isn't doing accessibility any favor?

    Yes, I agree. I'm not insisting that the fallback content isn't exposed to assistive technology; I just don't understand how it could work. Some kind of switching feature could be provided by the user agent and exposed to assistive technology so that assistive technology users could choose their preferred format, but I don't know how feasible that would be.

    Posted by Gez on

  20. [html5-image-element-no-alt.php#comment20]

    Is there a reason that <img> has to be an empty tag in HTML? Just thinking that if <img> could contain children, like <object>, then you could embed long alternate descriptions inside <img> tags and you might possibly avoid the ambiguities introduced by using <object>.

    Eg. 

    
<img>
  <h2>a description</h2>
  <p>Whatever should be exposed to AT</p>
</img>

    Posted by Jim on

  21. [html5-image-element-no-alt.php#comment21]

    D'oh! Think I've answered my own question - how can an inline element, <img>, have block-level children (headings, paragraphs etc)?

    Mind you, how could an inline <object> contain headings, paragraphs and lists as alternate content and still be valid? If I understand it correctly, <object> fallback content limits the author to inline content only, for inline images. Longdesc, on the other hand, allows for much more flexible, fully structured descriptions of the content of images.

    Posted by Jim on

  22. [html5-image-element-no-alt.php#comment22]

    Hi Jim,

    Mind you, how could an inline <object> contain headings, paragraphs and lists as alternate content and still be valid?

    The object element's content model can accept %flow;, which allows block level and inline elements.

    From the HTML 4.01 object element definition specification: 

    <!ELEMENT OBJECT - - (PARAM | %flow;)*

    So your idea of nesting block-level content inside the img element might also work, but I agree it sounds strange.

    Posted by Gez on

  23. [html5-image-element-no-alt.php#comment23]

    Jim, it could work for XHTML, and it has been proposed on the WHATWG list before, but it can't work in HTML because <img> has to be parsed as an empty element for legacy reasons.

    Problems include that it doesn't work in current browsers (the contents of the element are never exposed to the user) and that it introduces yet another difference between HTML and XHTML, and how it integrates with the alt attribute.

    Posted by zcorpan on

  24. [html5-image-element-no-alt.php#comment24]

    I must admit to being a little surprised that he favoured encouraging authoring tool vendors to drop alternate text, as opposed to encouraging authoring tool vendors to make it easier for their users to provide alternate text.

    Everyone agrees that authoring tools and sites like Flickr should allow users to provide alternate text, and we absolutely should encourage them to improve. But even if authoring tools did adhere to ATAG, we're never going to get all authors to provide alternate text. So the question still remains about what authoring tools should do when users don't provide it?

    We don't want them to automatically generate useless, poor quality alt text, but if allowing alt to be omitted in those cases isn't the right answer, then what is? Should they insert an empty alt? Should they redundantly repeat image meta data? Should they insert some generic placeholder text? Or maybe something else? They need to make the best of a bad situation; the question is how?

    The reason the spec favoured omitting alt over the empty alt="" was because at least UAs would make the user aware of the image and could attempt to provide repair text, whereas they would just ignore it completely if it had an empty value. However, it turns out that the problem with this approach, as Steve Faulkner has pointed out, is that it doesn't work well for sites like Flickr that generate horribly long numeric file names, which screen readers attempt to read out.

    Posted by Lachlan Hunt on

  25. [html5-image-element-no-alt.php#comment25]

    Hi Lachlan,

    We don't want them to automatically generate useless, poor quality alt text, but if allowing alt to be omitted in those cases isn't the right answer, then what is?

    I wish I could think of something that the specification could do to ensure that attribute values aren't abused, particularly for accessibility. Beyond making a strong statement that as something is essential for understanding, then it is a required attribute, I can't think of anything.

    I don't think poor alternate text is something that can be solved with the markup alone, but the HTML 5 specification does help a lot by providing some good guidance on how to specify alternate text, ignoring the overly verbose first example. It's then the responsibility of authoring tools (including web services) to make it easier for their users to provide the alternate text, and the responsibility of authors to provide good alternate text.

    Posted by Gez on

  26. [html5-image-element-no-alt.php#comment26]

    I wish I could think of something that the specification could do to ensure that attribute values aren't abused

    It doesn't matter what goes into the spec, it'll be ignored and abused. The specs are only any good to people that want to follow them, and that's not enough people.

    My suggestion would be that any document that doesn't strictly validate would generate a big error in all browsers, but sadly none of them have the balls to do that! *sad*

    Posted by Danny Tuppeny on

  27. [html5-image-element-no-alt.php#comment27]

    My suggestion would be that any document that doesn't strictly validate would generate a big error in all browsers, but sadly none of them have the balls to do that!

    (This somewhat off-topic, so I'll keep my response brief)

    Danny that's not balls - that's just harmful to end-users who've come to expect that things on the web "just work".

    For years browsers have been cleaning up the mess left for them to give the customer something reasonable to look at... from a customer interaction perspective this is a pretty reasonable thing to do. Sadly this behind-the-scenes work has made standardizing error handling a requirement to tackle any further innovation within HTML... hence HTML 5.

    Posted by Shawn Medero on

Comments are closed for this entry.