MINI FAQ ABOUT THE ALTERNATE TEXT OF IMAGES Written by Ian Hickson web: http://www.hixie.ch/advocacy/alttext e-mail: ian@hixie.ch 1. Introduction =============== The alt attribute specifies alternate text that is rendered when the image cannot be displayed. User agents must render alternate text when they cannot support images, they cannot support a certain image type or when they are configured not to display images. The alternate text is just that: alternate. In other words, it should be a textual alternative for the meaning of the image. It should convey the same thing as the image. Authors should not specify irrelevant alternate text when including images intended to format a page, for instance, alt="red ball" would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string (alt=""). Authors are in any case advised to avoid using images to format pages; style sheets should be used instead. Authors should not specify meaningless alternate text (e.g., "dummy text") either. Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output. 2. Typical Arguments ==================== If an image is missing, then its frame should, in my opinion, be removed and replaced by _inline_ text that represents the same information. That text is the alternate text from the "alt" attribute. Many people argue that the image dimensions should be preserved when an image is not shown. This document explains why I think this is not the case. Argument number #1: > The essential aspect of an image is its area. The essential aspect of an image is _not_ its area; it is its meaning. That the information is in graphical format is _not_ (usually) essential. (One possible exception to this rule would be optical illusions -- there, the graphical form of the meaning is indeed very much essential.) Argument number #2: > IMO, the essential problem here is a bug in HTML: there is no way > for an HTML author to explicitly define whether a specific image is > a replacement for text or an adjunct to text. All images are replacements for text. Or rather, both text and images are replacement for "meaning". That is to say, one can always be used instead of the other -- both can be used to convey meaning -- but sometimes one is much better at conveying a particular meaning than the other. Argument number #3: > Some images, when used as adjunct illustrations, really are worth a > thousand words, for example an image whose ALT text would be > "Screenshot showing Communicator 4.x Proxy settings for Indianapolis > campus." That would *never* be a valid ALT text. It would be valid content for the _title_ attribute, but not the alt attribute. The relevant alternate text would be something like: "The proxy settings dialog box has 'proxy.i.edu' in the 'host' field and '3128' in the 'port' field for every protocol." There should also be a page reading something like: ** Screenshot showing Communicator 4.x Proxy settings for Indianapolis campus. ** The image depicts the Proxy Settings dialog box for the Communicator 4.x application as it is set for the Indianapolis campus. The dialog box has four rows of edit boxes, labelled HTTP, FTP, GOPHER and HTTPS. Each row has two edit boxes, aligned in two columns, with the labels 'host' and 'port' at the top. Each 'host' field has the content 'proxy.i.edu' and each 'port' field has the content '3128'. This page should be linked to the tag using the "longdesc" attribute. The tag should therefore look like this: The proxy settings dialog box has 'proxy.i.edu' in the
        'host' field and '3128' in the 'port' field for every
        protocol. Note that the alt text is a replacement for the image, the title gives a brief description (caption) of the image, and the longdesc file gives a long description of the image. Once again: the alt text is NOT supposed to be a DESCRIPTION of the image, it is supposed to be an alternative representation of the MEANING of the image. Another example:

The house is white, with green shutters on the windows. The house is in the middle of...

...and NOT:

A white house with green shutters on the windows. The house is in the middle of...

This is quite an important distinction, which I fear may be difficult to explain to all the authors who still think the web is WYSISYG. Look at the first of those snippets, however, and think about how you would like it rendered if images are disabled (i.e. if the user has stated he does not want to see any images). I would suggest that the best rendering is: The house is white, with green shutters on the windows. The house is in the middle of... ...and not the following: +---------------------------------+ | The house is white, with green | | shutters on the windows. | | | | | | | +---------------------------------+ The house is in the middle of... The first is called "rendering the alt text inline", the second is "rendering the alt text in a placeholder box". Argument number #4: > Presumably the context of this image would be written directions, > but while both the image and the text are meant to improve > understanding of a topic, both have distinct roles and neither could > completely substitute for the other. Not perfectly, no. But if the image is not present, then correct alternative text, inline, is better than the image's title, in an otherwise empty box! (And anyway, an empty box looks ugly.) Argument number #5: > If, in this example, when the image failed to load, that ALT text > were placed in a box whose size was defined by the height and width > attributes, it would retain its semantic identity and provide a cue > that the entire content of the webpage is not at present available. > If that same ALT text were to appear inline with the same display > properties as the surrounding text, it could confuse. The reader of the page frankly couldn't care less if the author has made a mistake and the page is not completely available. The reader wants the information. So if an image is not available, the page should adapt. This is what alt text is designed to do. Argument number #6: > This page uses spacer GIFs, but because of an error on the part of > the webmaster, the IMG tags actually point to non-existent images, > and thus when the filename is displayed, it messes up the layout! Well then fix the page so that it points to a real spacer GIF! The page has a problem, it should be fixed. In any case, using images to control layout is deprecated in HTML. CSS should be used instead. Argument number #7: > But why use the filename! If there is no "alt" text, surely you > should display nothing, not the filename. According to HTML 4.0, we should use the filename: http://www.w3.org/TR/1998/REC-html40-19980424/appendix/notes.html#altgen HTML 4.01, the latest HTML4 spec, refers to the WAI User Agent accessibility guidelines, which are hidden behind a members-only section, so I cannot tell what should officially be done now, but it is probably not too dissimilar to the HTML 4.0 recommendations. (Note. Apparently, the WAIUAAG points to these documents: http://www.vorburger.ch/projects/alt/altpaper.html http://www.w3.org/WAI/ER/text-equiv.htm ...which I haven't read thoroughly yet.) Argument number #8: > How about if we did display ALT text (and if there is none, title, > name, or filename), but always in a box the size of the image (if > WIDTH and HEIGHT attributes are given). That way: (1) we'd always be > displaying ALT text (maybe make sure that the entire text is visible > by adding tooltips), (2) wouldn't have to worry about special cases, > and (3) wouldn't break any page layout (if images can't load or > image loading is turned off). This misses the fundamental point: that HTML is *NOT* about "page layout". If the page doesn't look like the author intended, then THAT IS WHAT IS HAPPENING ANYWAY if, e.g., fonts have been changed, there is a user stylesheet, author colours have been disabled, the browser is not graphical, the page is going through a sadistic firewall, or any number of other possibilities. If the image is a decorative graphic, then we can drop it altogether (this should be the alt="" case, but some heuristics may be needed to work out when an image is just decorative or used for layout, if it is missing the alt attribute). If the image is not decorative, and is in fact informative, then it should have a textual equivalent in the form of its alt text, and that is what we should show (or a synthesised version, e.g. from the filename or the title attribute). As has been previously mentioned, the important aspect of the page is not its layout, it is its content. If images are disabled, and a page relies on images for layout, then that's ok: forget the layout altogether, and simply draw the remaining text. Argument number #9: > ALT is an accessibilty issue: the aim is to provide access to > content where the primary format (in this case, images) can't be > viewed for various reasons. Not quite -- the aim is to provide access to the *intended* content. Argument number #10: > Saying that the alt text should be a textual alternative for the > *meaning* of the image misses a very frequent use of images as some > kind of interface tool (anchor link, imagemap, etc). I don't mean to exclude those uses. What's the _meaning_ of an image of a button that says "submit"? The meaning is "submit". So the alt text should be "submit". It should convey the same thing as the image, namely, at the risk of sounding repetitive, "submit". Argument number #11: > I tend towards expressing the general principle in terms of the ALT > text being a "functional text-mode replacement for the _purpose_ of > the image in its context" (or something like that). I disagree. The functional text-mode replacement of the purpose of a decorative image would probably be some ASCII art, and yet that is inappropriate alt text. Alternative text is not only used in text media, speach media also use alternative text. Hence why I say *textual* alternative and not text *mode* alternative. 3. Conclusion ============= Have you ever looked at what Lynx does with pages containing images? When the author has written correct alternative text, the reader still gets all the information, although obviously in a slightly less efficient way than with them. But the reader is not told "Ooh, sorry, my information is only worth reading if you can see images". Mozilla and Lynx are now doing this almost correctly (for Mozilla, see bug 1994, I am not aware of any web page covering the problems with Lynx's interpretation). See also bug 23691. 4. Acknowledgements =================== Thanks to various experts in the community, including Alan Flavell and Matthew Thomas. As usual, any mistakes are my own. -------------------------------------------------------------------------- ********** See also http://www.hixie.ch/specs/alttext ********** -------------------------------------------------------------------------- Given that, here are some replies to Matthew's comments (which I largely agree with): > * Minimum acceptable size for an image placeholder (so as to get at > its context menu, or click to load it) would be about 16*16 pixels > -- it should never be smaller. So for all those 1*1-pixel graphics, > the placeholder won't be the same size as the image anyway; and if > we used the image's size for all images except those smaller than 16 > pixels in either dimension, we could give a false impression about > how large those small images were. I don't know that we actually _want_ the user to be able to get to those particular images in the first place... have you thought of the mess some pages would turn into, if every 1x1 transparent pixel GIF turned into a 16x16 icon??? > * Better incremental display if the image loads, which it usually > will. We could just use a sized placeholder during the loading, and > revert to an unsized placeholder if the image fails (this is the > behavior complained about in bug 40623); but that could mean a > sudden reflow a couple of minutes (!) after everything else on the > page had completed, when Mozilla gave up on getting any response > from the image's server. We have that problem anyway with going in the other direction. However we do it, there is no way we can reliably get the placeholder frame the right size initially without the "height" and "width" attributes being known to us. Might as well go for the solution which gives the least difference each time. (Sized if we know the size in advance, inline if we don't.) > * Scrooge scenario: I load a page without images, and see all their > sized frames. I use the context menu to hide/block those images > which, based on their size, look Unlikely To Be Useful, and then > click the Images button. This scenario only works if the frame is > sized in the first place. Hopefully my "Load Images On Demand" mode allows this while still leaving the option of disabling images completely. > I think offering three modes is a large mistake, because it will > have an *extremely* low usefulness-to-confusion ratio. Agreed. I was `forced' into suggesting this pref because of a conflict between your previous statements and my own views. Since your views have basically changed (see below), this can be removed altogether. > `Don't Load Images' [...] The choice your pref offers [...] is > whether pages designed around the HTML specs stuff up, or whether > pages designed around legacy browsers stuff up. It was actually included so that you could use your "Scrooge scenario": loading a page without images, and then, based on all their sized frames, using the context menu to hide/block those images which look Unlikely To Be Useful. If that is not a high priority, then I am happy to remove the possibility of doing this since it simplifies everything. > `Show icons for _all_ images' [...] In Mozilla showing icons for all > unloaded images is an order of magnitude more important than it is > in Lynx, because Mozilla can't get away with assuming that all you > want to do with images is show their alt text (and occasionally open > them in an external viewer). This is why I had three prefs: 1. You want images (graphical browser), 2. You want images, but only when you ask for them, 3. You don't want the images at all (text browser). There is no way we can have "show icons for all images" enabled by default (and the only option) -- that would make pages literally unreadable. If you don't believe me, try browsing the web with the following in your html.css file: img[width="1"] { padding: 0.5em !important; border: solid red !important; } img[width="2"] { padding: 0.5em !important; border: solid red !important; } img[width="3"] { padding: 0.5em !important; border: solid red !important; } img[width="4"] { padding: 0.5em !important; border: solid red !important; } img[width="5"] { padding: 0.5em !important; border: solid red !important; } img[height="1"] { padding: 0.5em !important; border: solid red !important; } img[height="2"] { padding: 0.5em !important; border: solid red !important; } img[height="3"] { padding: 0.5em !important; border: solid red !important; } img[height="4"] { padding: 0.5em !important; border: solid red !important; } img[height="5"] { padding: 0.5em !important; border: solid red !important; } Try, for example, some of the following: http://home.netscape.com/ http://www.microsoft.com/ http://www.hp.com/ http://www.ibm.com/ http://www.bbc.com/ It is extremely nasty. Now, instead of the above lines, insert the following: img[width="1"] { display: none !important; } img[width="2"] { display: none !important; } img[width="3"] { display: none !important; } img[width="4"] { display: none !important; } img[width="5"] { display: none !important; } img[height="1"] { display: none !important; } img[height="2"] { display: none !important; } img[height="3"] { display: none !important; } img[height="4"] { display: none !important; } img[height="5"] { display: none !important; } ...and try those sites again. (Note that the above is only a rough approximation of what it would really feel like, so don't draw too many conclusions from this.) > Having a special ALT case for images measuring 0 or 1 in one > dimension is only useful, under your spec, if those same images also > happen to have a TITLE, NAME, or ID value (in which case those > attributes would be ignored instead of used). Agreed. That was a relic of my spec at a time where I was still thinking of using the filename to generate the alternate text. > In deriving alt text from non-ALT attributes, I think ID should come > before NAME, Ok. > I still think that image frames should be unsized until they start > loading, even if we know their WIDTH and HEIGHT; because it is far > more acceptable for layout to jump around five seconds after the > page begins loading (when the image starts loading and we give it a > sized frame), than it is for the layout to stabilize after ten > seconds but then jump around two minutes after the page begins > loading (when the image server times out and we turn its sized frame > into in-line alt text). As David R said, working images are a _lot_ more common than those that time out. Your way, the page is *guaranteed* to be reflowed. If we size as much as possible while loading, then only broken and unsized images will reflow. In fact, doing it this way will encourage good authoring practice: if authors include height and width on all their images and make sure they have no broken images, we will have no reflows whatsoever! -------------------------------------------------------------------------- See also http://bugzilla.mozilla.org/show_bug.cgi?id=41924#c154 -------------------------------------------------------------------------- ---end---