- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 10 Apr 2008 22:11:38 +0000 (UTC)
The HTMLWG's ISSUE-31 is "Should img without alt ever be conforming". It isn't clear from this issue what exactly the problem with the current spec text is. The current text in the spec requires alt="" in all cases except when the page is generated in a manner where alternative text is not available, or when there is no possible way to provide text that is in any way a replacement for the image. Two examples are given, namely a photo upload site, and a Rorschach inkblot test. In the former case, the image is generated automatically and the program simply does not have enough information to provide alternative text. In the latter case, _any_ description would miss the point of the test (which is to see what descriptions people come up with). The spec contains very strong wording requiring alternative text in all manner of possible situations, and encouraging it even in the aforementioned cases. I'm not sure what else we can do short of just making it non-conforming to create bulk-upload image hosting sites or write documents that contain inkblot tests. If the issue's title is ever to be answered in the negative, it would be helpful for solutions to the two examples above to be provided. I've closed the issue, to indicate that I have examined it in detail and come to a tentative conclusion. Further input from anyone, but in particular the PFWG, is welcome and encouraged; if anyone disagrees with this issue they are of course encouraged to reopen the issue in the issue database, preferably at the same time as providing further information to help answer the issues given above. :-) Here are some answers to other issues raised on the topic: On Thu, 6 Jan 2005, James Graham wrote: > Matthew Thomas wrote: > > > > For perhaps 95 percent of the images on the Web, the most appropriate > > alternate text is nothing at all. (In 2003 I did a survey of images in > > Wikipedia articles, where images aren't even used for decoration, and > > still found that alt="" would be the most sensible choice for 77 > > percent of them.) So for that 95 percent, assuming that no alt is > > alt="" would improve the user experience. > > > > Unfortunately, the other 5 percent would ruin the idea. When > > screenreaders are wading through inaccessibly-written pages, sometimes > > images are used for navigation (graphical menus, for example), so the > > user needs an indication that an image is there (whereupon they can > > guess its function by its URI). Assuming that all these images had > > alt="" would make such pages completely unnavigable. > > Both this and the other point that Jim made (implied alt is hard to > debug) strongly suggest that alt should be optional, not implied. The > lack of an alt attribute would legitimize any inference about suitable > alternative text that the web browser wanted to perform. Therefore it > would remain best practice to explicitly declare alt="" where the image > is purely decorative. I expect many web developers would favor this > approach since the validator complaining about a lack of alt="" has been > perceived as unnecessary nannying and so the requirement has widely been > ignored. Making alt optional probably wouldn't damage accessibility as > much as might be thought because a) bad alt text is at least as bad as > missing alt text and b) there exist other tools that explicitly check > documents for accessibility which could flag missing alt attributes. This is the reasoning behind the current wording of the specification. On Thu, 6 Jan 2005, Andrew Kirkpatrick wrote: > > Alt should be required on inputs of type=image, area elements, and perhaps > on images within anchors (although images within an anchor that also > contains text or another image with alt could be fine without alt also, so > I'm not sure how to best handle that). The form control issues (input type=image) are pending a result from the forms task force (I don't want to write that part of the spec only to find the whole thing has to be rewritten). Omitted alt="" attributes only make sense (and are only, reluctantly, allowed) when the site serving the image simply has no idea what the image is, but knows that it is important. One could easily imagine a situation where that is the case, but where the image is in a link. For example, any image on Flickr that doesn't have useful metadata falls into this category. Thus I don't think we can make that requirement, as it would only lead to nonsense alt text or the concept of validity being ignored altogether. > As a person who works in the area of accessibility, I'm inclined to > agree that alt doesn't really need to be required. What is unusual is > that not only is this a solid idea theoretically, but the user agent > base supports it already. That's good to know. > Users can, and probably would continue to be able to, get their user > agent to voice all images without regard to the presence of alt if they > wanted. Having alt be required is an argument that assumes that > developers will examine their images more carefully in order to achieve > valid code. Unfortunately, this doesn't seem to really work, and the > important task of adding quality equivalents for just important images > is often lost in the sea of unimportant images that need alt="". Agreed. On Sat, 21 Jan 2006, Matthew Paul Thomas wrote: > > Ah, of course, I had forgotten about <input type="image">. It would have > been more obvious to make alt= compulsory where type="image", and > prohibited otherwise. I imagine we will require this, assuming we keep <input type=image>. On Fri, 20 Jan 2006, Alexey Feldgendler wrote: > On Fri, 20 Jan 2006 21:13:40 +0600, Henri Sivonen <hsivonen at iki.fi> wrote: > > > > The bottom line is that requiring the presence of the alt attribute > > leads to a situation where UAs cannot tell whether the alt text is > > empty because the image is purely decorative or because the author did > > not bother to think about it. > > > > IMO, this leaves the people who don't see the images worse off > > compared to a scenario where an empty alt text signified a purely > > decorative image and a missing alt attribute signified that the author > > did not bother to provide a textual alternative. > > Thanks, you expressed what I was trying to say much better than I did. I agree. On Tue, 24 Jan 2006, Henri Sivonen wrote: > On Jan 23, 2006, at 18:43, dolphinling wrote: > > > > Second, it could force authoring tools to produce invalid documents if > > the author did not provide any alt text. However, those documents > > would be non-conformant anyway, so this is not a huge problem. > > It is. Authoring tools are judged by taking a page authored using the > tool and running it through the W3C Validator or, presumably in the > future, through an HTML5 conformance checker. Authoring tool makers who > are capable of making their tool produce syntactically conforming > documents will want to do so and minimize the chance that the users of > their software tarnish the reputation of the tool in the eyes of people > who use an automated test as a litmus test of authoring tool bogosity. > (People who test tools that way will outnumber the people who make a > more profound analysis due to the "validate, validate, validate" > propaganda.) Indeed. On Tue, 24 Jan 2006, dolphinling wrote: > > File -> Save > > "If you save this page as is, it will be non-valid for the following > reasons: > > You did not specify alternate text for one or more images. > > The page will display properly, but will be less accessible to some > users and will fail automated validation tests. > > [Fix errors] [Save anyway]" > > ...The point being that that would only be a problem to authoring tools > that didn't do something about it--and frankly, I'd expect an authoring > tool to give a dialog like that anyway, even if they weren't concerned > about market share. I think such UAs would likely frustrate many of its users (and would then lose those users). On Tue, 24 Jan 2006, Henri Sivonen wrote: > > You are being dogmatic about the alt text to a point of suggesting an > annoying modal dialog. Usually, needing a modal dialog is a bad sign. > > Also, your solution does not solve the problem I outlined: It would > allow users to hit enter and other users would conclude that the tool > produces non-conforming markup. Therefore, the toolmaker is unlikely to > do what you suggested. Indeed. On Wed, 1 Nov 2006, Christoph P?per wrote: > > I consider > > <a href="foo.xga"><samp><img src="foo.qvga" alt="Foo"></samp></a> > > more semantic than the frequent > > <a href="foo.xga"><img src="foo.qvga" class="thumbnail" > alt="Foo"></a>. > > Alas nobody is using it that way. (What kind of |rel| could one use for > this kind of links BTW?) That's probably not especially useful semantics, but I agree that it is hard to argue against it. :-) On Tue, 14 Nov 2006, Charles Iliya Krempeaux wrote: > > Thinking about it some more, something like the <q> element may be > useful as well for marking thumbnails. > > So, you might have something like this... > > <a type="video/mpeg" href="http://example.com/video/123"> > <q cite="http://example.com/video/123"> > <img src="http://example.com/thumbnail/123" /> > </q> > </a> > > (Although you'd probably want to add a "quotes:none;" to that <q> > element, since some browsers wrap a <q> with quotes.) > > One would know that the <img> is from the video because the URL in > "cite" attribute (for the <q> element) matches the URL in the "href" > attribute (of the <a> element.) I guess that's also technically sane. I don't see much advantage to doing that though. :-) On Tue, 14 Nov 2006, Charles Iliya Krempeaux wrote: > > Doing it this way (with the <q> element instead of the <samp> element) > would also allow you to take the thumbnail outside of the link. So, for > example... > > <q cite="http://example.com/video/123 "> > <img src="http://example.com/thumbnail/123" /> > </q> > <a type="video/mpeg" href="http://example.com/video/123">[download]</a> > > The "cite" attribute (of the <q> element) and the "href" attribute (for > the <a> element) could still be matched up to find thumbnail, in this > configuration too. I think in practice people don't need to worry about this level of "semanticism" for the sake of itself. On Wed, 15 Nov 2006, Charles Iliya Krempeaux wrote: > > If we still had the "urn" attribute on the <a> element, we could use it > to specify alternatives of the same video. > > So, for example... > > <q cite="http://example.com/video/123/mpeg"> > <img src="http://example.com/thumbnail/123" /> > </q> > <a urn="urn:uuid:0a8d2f83-d5d2-44e7-bde9-319aaadc219c" type="video/mpeg" > href="http://example.com/video/123/mpeg">[MPEG]</a> > <a urn="urn:uuid:0a8d2f83-d5d2-44e7-bde9-319aaadc219c" > type="video/quicktime" href="http://example.com/video/123/mov > ">[QuickTime]</a> Ok that just seems overly complex. > Any chance we can get the "urn" attribute on the <a> element back? :-) Not based on _that_ example... :-P On Thu, 8 Feb 2007, Nicholas Shanks wrote: > > I wish the <image>fallback</image> tags had made it through the years. > It's so much better than <img alt="blah"> and doesn't suffer from the > self-closing-tag-in-html problem. Sadly <image> as a tag name is taken by the legacy content (and maps straight to <img>); but in any case <object> handles this case pretty well. On Fri, 9 Feb 2007, Nicholas Shanks wrote: > > The basic point of replacing <IMG> with <IMAGE> rather than replacing it > with <OBJECT> was (would be) specificity. The image element could now be > defined as a subtype of the object element for that most common usage > case of including pictures on a page. I don't see a pragmatic reason to support this over <object> (unlike <video>, <img> doesn't have an especially useful DOM API that <object> couldn't, and doesn't, provide). On Wed, 11 Apr 2007, Maciej Stachowiak wrote: > > This topic came up on #html-wg today. > > Mail.app and other mail clients don't put alt attributes on images > generated in email. They could add alt="", but there are two reasons it > might be better to allow no alt attribute at all, at least for email > clients. > > 1) A mail message is often sent to a restricted audience, so the > accessibility, media-independence and machine-understandability benefits > or alt are not nearly as great. And adding alt="" as a cargo cult > talisman does not give these benefits in any case. > > 2) WYSIWYG editors in general can't be expected to enforce proper alt > attributes. Users can add images in all sorts of ways (paste, drag and > drop) that don't have a natural affordance for entering alternate text. > And I doubt WYSIWYG editors that popped up a box for typing in text > whenever the user inserts an image would be competitive > > > In general, I think the HTML5 definition of <img> is problematic - it > says: > > "The img element represents a piece of text with an alternate graphical > representation." > > And also: > > "When the alt attribute's value is the empty string, the image > supplements the surrounding content. In such cases, the image could be > omitted without affecting the meaning of the document." > > > Let's consider one archetypical use of the <img> tag in the wild, a > Flickr photostream. The example below is from my photostream. > > <IMG src="http://farm1.static.flickr.com/178/392969604_a0887f39ce_m.jpg" > width="240" height="180" alt=""> > > I don't think it is right to say that this represents a piece of text > with an alternate graphical representation - it represents an image, > namely the linked photo. It's also not right to say that the image could > be omitted without affecting the meaning of the document. Although I > entered a title of "Frisson: White truffle & wild rice", it would be a > strained interpretation to say my photostream page would have the same > meaning without any of the photos. Also, Flickr lets me have no title at > all, or an ugly title based on the camera- chosen file name like > DSC0981.JPG. The spec has been changed to make alt="" optional in this particular case. On Thu, 23 Aug 2007, Lachlan Hunt wrote: > > I think it would be good if the spec included a set of examples to > explain that the alt text is dependent upon the context in which the > image is used, and the purpose it is used for. So the same image may be > used in different locations and have entirely different alt text. > > For example, and picture of a flag, such as the Australian flag, may be > used in different contexts. > > * As a link to a localised version of a site. > <a href="/au"><img src="aus-flag.png" alt="Australia"></a> > > * In an article about the flag itself > <img src="aus-flag.png" > alt="The blue Australian flag features the red and white Union > Jack in the top left corner, 5 white stars representing > the Southern Cross on the right hand side and the 7-point > Federation Star in the lower left corner below the Union > Jack."> Added an example to this effect. On Thu, 23 Aug 2007, Sander Tekelenburg wrote: > > I think the "Fluffy" examples we used in the "unifying alternate content > across embedded content element types" thread could be useful. In that > thread we actually bothered to think up different contexts already. These are good examples. I have used them. Let me know if there's anyone in particular I should acknowledge. On Sun, 26 Aug 2007, Lachlan Hunt wrote: > > I think the description for alt text in the section titled "A key part > of the content that doesn't have an obvious textual alternative" needs > to be rewritten. [1] > > Firstly, change the title to "A key part of the content". > > I think these first 2 paragraphs from that section should be replaced. > The spec currently states: > > > In certain rare cases, the image is simply a critical part of the > > content, and there might even be no alternative text available. This > > could be the case, for instance, in a photo gallery, where a user has > > uploaded 3000 photos from a vacation trip, without providing any > > descriptions of the images. The images are the whole point of the > > pages containing them. > > > > In such cases, the alt attribute may be omitted, but the alt attribute > > should be included, with a useful value, if at all possible. If an > > image is a key part of the content, the alt attribute must not be > > specified with an empty value. > > The following is my proposed replacement: > > --- > > In some cases, the image is a critical part of the content. This could > be the case, for instance, in a photo gallery, a series of screenshots, > or a comic strip. In such cases, authors should provide suitable > alternate text. When suitable alternate text is available, it must be > included in the alt attribute. > > Example: > <figure> > <legend>Cat Proximity</legend> > <img src="http://imgs.xkcd.com/comics/cat_proximity.png" > alt="As a human approaches a cat, intelligence decreases and the > inanity of statements increases. e.g. A man says to a cat: > 'You're a kitty!'"> > title="Yes you are! And you're sitting there! Hi, kitty!" > </figure> > > However, even if an authoring tool allows for alternate text to be provided, > there are some cases where authors will still fail to do so. For example, > where a user has uploaded 3000 photos from a vacation trip, without providing > any descriptions of the images. In those cases, the alt attribute must be > omitted; it must not be specified with an empty value. > > [insert remaining content, beginning with the photo sharing and screenshot > examples] > > --- I haven't used exactly the above, but I've used something like it. > The spec could possibly also include a requirement for authoring tools > to provide a mechanism for the author to provide alt text, perhaps with > a reference to the ATAG spec. I'm not sure that would be useful. On Sun, 26 Aug 2007, Lachlan Hunt wrote: > > This page [1] lists a lot of different image categories and describes what > type of alternative text to provide. The spec seems to cover most of the > relevant categories already, though it should probably address advertising > banners/interstitials and CAPTCHA images. If you do include CAPTCHA images, > you should probably also reference the W3C note about them [2]. > > [1] http://html.cita.uiuc.edu/text/ > [2] http://www.w3.org/TR/turingtest/ I'm not really sure what to say about either that would help. On Tue, 11 Sep 2007, Jon Barnett wrote: > > There is a Real Problem we're trying to solve. Since it's not clear > to me by reading this mess that this problem is understood, I'll try > to state it clearly. > > On the web, images are used in various ways. Sometimes, an image is > iconic and represents text, such as in a menu like this: > [1] <li><a href="..."><img src="home.jpg" alt="Home"></a> > <li><a href="..."><img src="about.jpg" alt="About Us"></a> > <li><a href="..."><img src="store.jpg" alt="Store"></a> > <li><a href="..."><img src="blog.jpg" alt="Blog"></a> > > There is no disagreement that alternate text is correct. > > Sometimes images are not iconic, but are integral to the meaning of a page: > > [2] <img src="grand-canyon.jpg" alt="The grand canyon as viewed from > the east at sunset"> That's appropriate title="" text, not alt="" text, for what it's worth. > Clearly, that text can't be considered an equivalent for the image - > can a few words replace the grand canyon? No, the the presence of the > image is important. A screen reader user needs the presence of the > image announced so that the user knows they're hearing a description > of a picture and not a random sentence out of context. > > So, since JAWS can't really tell the difference between [1] and [2], > it sounds from your tests that JAWS announces the presence of the > image. If it announces the presence of every image [1] gets read as > "Linked Graphic Home Linked Graphic About Us Linked Graphic Store ..." > Does a blind person really need to be taunted with the presence of 5 > or 6 images in a navigational menu? On the other hand, if JAWS did > NOT announce the presence of an image, [2] would just be read as "The > grand canyon as viewed from the east at sunset" - a single sentence > out of context with no indication that there's an image. Indeed. > Since @alt is required by HTML4, we often see authors insert text even > when it doesn't belong, such as a list of icons accompanied by text: > [3] <li><a href="..."><img src="home.jpg" alt="Home">Home</a> > <li><a href="..."><img src="about.jpg" alt="About Us">About Us</a> > <li><a href="..."><img src="store.jpg" alt="Store">Store</a> > <li><a href="..."><img src="blog.jpg" alt="Blog">Blog</a> This, as noted in the spec, is bad practice, as you note: > This, even without announcing the presence of an image, is confusing > when read as "Home Home About Us About Us Store Store Blog Blog". So, > authors are encourages to simply leave @alt blank: > [4] <li><a href="..."><img src="home.jpg" alt="">Home</a> > <li><a href="..."><img src="about.jpg" alt="">About Us</a> > <li><a href="..."><img src="store.jpg" alt="">Store</a> > <li><a href="..."><img src="blog.jpg" alt="">Blog</a> > > That way, a screenreader knows to ignore the image. Right. > But since authors are allowed to just leave @alt blank, they may not > bother describing the grand canyon: > [5] <img src="grand-canyon.jpg" alt=""> They might not bother whether they're allowed to or not. :-) > Using the logic from [4], the screenreader might think the image can be ignored. > > That's the problem the draft attempts to solve. It distinguishes > between [4] (a graphic that can be ignored) and [5] (a meaningful > graphic where the author refused to give any helpful text). My > suggestion earlier in this thread was to use @title to describe a > meaningful image so there is some accessible text without implying that > text is "equivalent" to the image. That would be reasonable, yes. On Wed, 12 Sep 2007, Steve Faulkner wrote: > > A common use of an image that is not currently covered in the examples > provided: > when an image is the sole content of a link: > > <a href="homepage.html"><img src="logo.jpg" alt ="home"></a> > In cases where an image is the sole content of a link then the alt content > should be a brief description of the link target. Is the example for "Movies" and "Podcasts" not enough? It's the same idea. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 10 April 2008 15:11:38 UTC