The alt="" attribute

Ian,

Here is my perspective  on this issue after reviewing the various
options we have. I've taken the liberty of adding in one
suggestion of my own as part of this proposal --- namely, add  an 
img.getEXIFData() DOM method that returns the EXIF metadata for
an image as a JSON dictionary.

Ian Hickson writes:
 > 
 > How to mark up images has been a controversial subject in the development 
 > of HTML5. A number of people have put forward contradictory proposals. 
 > There has been much disagreement about what we can reasonably require of 
 > Web authors and users. There has also been disagreement about exactly to 
 > what extent we should allow people to write Web pages when making them 
 > perfectly accessible would be what they consider undue effort.
 > 
 > It has also been one of the areas that has had the least amount of 
 > research and data presented, relative to the amount of opinion put 
 > forward. This has made making informed decisions quite difficult.
 > 
 > 
 > We are faced with a number of proposals, which I have attempted to list 
 > here in no particular order. I'm sure I missed some, for which I 
 > apologise.
 > 
 > A. Require that every <img> element have an alt="" attribute specified, 
 > and require that every alt="" attribute have a non-empty value.
 > 
 > B. Require that every <img> element that the author believes conveys 
 > information that could not be removed from the page without changing the 
 > page's message have an alt="" attribute with a non-empty value, and 
 > require that the other <img> elements have an alt="" attribute with an 
 > empty value.
 > 
 > Variants:
 > 
 > B.1. Do not allow pages to be written that contain <img> elements for 
 > which suitable alternative text isn't available.
 > 
 > B.2. Allow pages that contain <img> elements for which suitable 
 > alternative text is for some reason not available to still be conforming, 
 > by:
 > 
 > B.2.i. ...allowing those <img> elements to have the alt="" attribute 
 > omitted altogether.
 > 
 > B.2.ii. ...having some special syntax for those <img>s' alt=""s:
 > 
 > B.2.ii.a. A special keyword in alt="".
 > 
 > B.2.ii.b. A set of special keywords for alt="" for various situations in 
 > which this may be possible.
 > 
 > B.2.ii.c. A special syntax for alt="" that provides free-form minimal 
 > alternative text to be given.
 > 
 > B.2.iii. ...having some new attribute for those <img>s:
 > 
 > B.2.iii.a. A free-form field for minimal alternative text, plus requiring 
 > that attribute to be present and alt="" to be absent.
 > 
 > B.2.iii.b. A set of special keywords for various situations in which this 
 > may be possible.
 > 
 > B.2.iii.c. A boolean attribute, plus:
 > 
 > B.2.iii.c.I. ...requiring that attribute to be present and alt="" to be 
 > absent.
 > 
 > B.2.iii.c.II. ...requiring that attribute to be present and alt="" to be 
 > present with some minimal alternative text.
 > 
 > B.2.iii.c.III. ...requiring that attribute to be present and alt="" to be 
 > present with one of a set of special keywords for alt="" for various 
 > situations in which this may be possible.
 > 
 > B.2.iv. ...requiring the alt="" in these cases to be included with some 
 > value that isn't actually replacement text, but is instead some minimal 
 > alternative text, without giving the user agent a way to distinguish this 
 > image from an image that has alternative text that is adequate for 
 > complete substitution.
 > 
 > B.2.v. ...requiring that all such images be in a link that points to the 
 > image itself.
 > 
 > B.2.vi. ...requiring that all such images be in a link that points to the 
 > image itself or in a <figure> element with a <legend>.
 > 
 > B.3. Have multiple levels of conformance, and only allow pages that 
 > contain <img> elements for which suitable alternative text isn't available 
 > to conform to a "lesser" level.
 > 
 > C. Require that alternative text be provided for simple images, but say 
 > that for more complex images, the alternative text be replaed by "greek 
 > text" (a placeholder that indicates the image is complex but doesn't 
 > actually convey the image's meaning).
 > 
 > D. Allow every <img> element to have alternative text provided but not 
 > actually requiring it.
 > 
 > E. Do not allow alternative text to be provided at all.
 > 
 > 
 > To pick between these we have to use what little research we have so far. 
 > This consists of the following. I hope I haven't missed anything; if I 
 > have, please let me know.
 > 
 >  * We have data showing that there are pages that have images that have no 
 >    alternative text available where the generators of the HTML are not 
 >    able to obtain that data.
 >    Evidence:
 >    http://lists.w3.org/Archives/Public/public-html/2008Aug/0602.html
 >       
 >  * We have shown that requiring alt="" attributes does not lead to image 
 >    sharing sites requesting alternative text from their users.
 >    Evidence: HTML4 requires alt="" attributes, yet Flickr doesn't require 
 >    users to enter alternative text.
 > 
 >  * We have data showing that such sites are major sites and are an 
 >    important part of the Web ecosystem.
 >    Evidence:
 >    http://www.alexa.com/site/ds/top_sites?ts_mode=global&lang=none
 > 
 >  * We have data showing that braces are not used often in alt="" 
 >    attributes.
 >    Evidence:
 >    http://philip.html5.org/data/alt-in-braces.txt
 >    http://damowmow.com/temp/alt-in-braces.txt
 >    http://krijnhoetmer.nl/irc-logs/whatwg/20080603#l-65
 >    http://krijnhoetmer.nl/irc-logs/whatwg/20080803#l-8
 > 
 >  * We have data showing that two thirds of pages have at least one <img> 
 >    element that is missing an alt="" attribute, and a tenth of pages have
 >    at least one <img> element but none of them have an alt="" attribute:
 >    http://krijnhoetmer.nl/irc-logs/whatwg/20080803#l-15
 > 
 > I have also watched a number of usability studies with visually impaired 
 > users browsing the Web, from which I have noticed the following:
 > 
 >  * Users get so much repetition from their screen readers that they tune 
 >    it out. It's not unusual for a page titled "Bee keeping", say, to sound 
 >    like this from a screen reader: "Bee keeping. Bee keeping. Graphic. Bee 
 >    keeping. The practie of keeping bees is as old as...". Users don't even 
 >    comment on this, but it is quite clear that it isn't optimal and in 
 >    fact in certain cases it is even actively harmful, because it drowns 
 >    out more important information, for example in one study I examined, 
 >    the user was at one point looking for a link on a page and it took him 
 >    two or three scans through the section to find the link because instead 
 >    of saying the equivalent of "Bee keeping. Link.", it said something 
 >    akin to "Bee keeping. Graphic. Link. Bee Keeping. Bee Keeping."
 > 
 >  * Users don't seem to navigate by images much. Navigating by headers 
 >    seems to be the most common, followed by navigating to the top of the 
 >    page, navigating by line, and navigating along forms and tables. This 
 >    could naturally be biased by the small sample of tasks in the studies I 
 >    saw, but in none of the studies did the users even mention ever doing 
 >    it, so even if it is occasionally done it doesn't seem common.
 > 
 > 
 > People have argued many things, which I have listed below with some 
 > commentary.
 > 
 > 
 > On Thu, 7 Aug 2008, John C. Vernaleo wrote:
 > > 
 > > I don't know much about screen readers, but I do know something about 
 > > LaTeX, and I just don't see how the textual representation of equations 
 > > scales very well past very simple equations.  Even in the example here 
 > > that sentence is just barely unambiguous.  A more complex equation would 
 > > be much worse and a matrix basically impossible.  And I'm not convinced 
 > > a human could do it any better than a program could.
 > 
 > The solution for mathematics in HTML5 is MathML, so I don't really wat to 
 > spend too much time considering the legacy practice of using images with 
 > LaTeX fallback alt="" text.
 > 
 > 
 > On Fri, 8 Aug 2008, Philip Taylor wrote:
 > > 
 > > There are other instances of the same problem - e.g. if I write a Web 
 > > 2.0 Logo Generator that converts a user's text into an image in a 
 > > certain typographical style, I would decide to set the alt text to be 
 > > what the user typed in, because that's the closest the tool can get to 
 > > an equivalent of the image; but then if the user types in some funky 
 > > name for their site like "{Cuilr}", it'll trigger the special 
 > > alt-attribute-gives-kind-rather-than-textual-equivalent processing in 
 > > HTML 5 UAs, which is inappropriate and harmful here, so I'd have to 
 > > worry about preventing that situation.
 > 
 > On Fri, 8 Aug 2008, Dave Singer wrote:
 > > 
 > > [...] we have to trade off whether that processing step (if first-char 
 > > of user-text is "{" then pre-pend something) is worth it to get the 
 > > feature we want -- really forcing people to think about whether they 
 > > truly lack alt text, and if so, getting them to indicate why.
 > > 
 > > Personally, I think it worth it, because the gain for one segment of the 
 > > population (those needing alt text) is much greater and more important 
 > > than the small pain for another (tool writers). [...]
 > 
 > On IRC, Philip Taylor wrote:
 > > 
 > > I think the described "gain for one segment of the population (those
 > > needing alt text)" comes from having any mechanism that gives a
 > > textual description of an image when no equivalent is available (and
 > > that requires authors to always write something, and hence to think
 > > about alt and (with non-zero probability) write something that's
 > > better than nothing); and this particular "small pain for another
 > > (tool writers)" is specific to the curly-brace syntax and doesn't
 > > seem to be a problem in any other proposed mechanism, because the
 > > other mechanisms don't add any complexity to the otherwise-pleasant
 > > situations where you really do have equivalent text.
 > >
 > > I think the gain is worthwhile, so I wouldn't want to go back to alt
 > > being optional; but I think the pain is real, so I'd prefer some
 > > other solution that has the same gain without the pain, but that
 > > involves tradeoffs against the pains (of varying levels of
 > > theoreticality) of other solutions, which is not trivial (if it's
 > > even possible) :-(
 > 
 > On Sun, 10 Aug 2008, Smylers wrote:
 > > 
 > > However, Ian showed that very few images currently have alt text 
 > > delimited by braces.  So, even though the above scenarios obviously 
 > > could exist, they apparently don't do so in large numbers.
 > > 
 > > So it may be that the net effect of the 'braces' proposal would be to 
 > > improve alt text on many more images than legitimately otherwise have 
 > > braces embracing their alt text -- such that a mis-interpreting a few 
 > > 'false positives' is, on balance, a price worth paying.
 > 
 > On further reflection, the image category does not seem that useful
 > anyway in the case of reading a page linearly. Off-hand I can think of
 > four cases where it might be used:
 > 
 >  * Photo-upload sites: The sites know less about what the image actually 
 >    is (screen shot, photograph, diagram, etc) than the users visiting the 
 >    page -- even if the users are blind or have images disabled, the odds 
 >    are that the context in which they reached the page, or the page's 
 >    title or comments, will be more useful in determining the type of image 
 >    than anything the site could offer.
 > 
 >  * Fractal navigation, satellite imagery navigation, and other automated 
 >    views of large bodies of graphical data: The user already knows that 
 >    the image is a fractal, a map, or whatever. Once again, explicitly 
 >    calling this out specifically in the context of the image will do 
 >    nothing to help the user.
 > 
 >  * Webcams: The text surrounding the webcam will most likely cue the user 
 >    into the purpose of the image. In most cases, if the user is not 
 >    specifically looking for a webcam (e.g. by visiting the webcam's 
 >    dedicated page directly), the user would likely not care about the 
 >    webcam anyway.
 > 
 >  * Blogs or galleries where there are photos that a blind photographer has 
 >    made available for his friends: The context will almost always cue the 
 >    user into the fact that the unknown images are photographs, so 
 >    explicitly having image category information isn't likely to be useful.
 > 
 > Pages aren't always read linearly, though. In particular, it has been 
 > pointed out that speech synthesis users can navigate pages image by image. 
 > For this, they need orientating. (More research on this topic really would 
 > be useful. I couldn't find any videos of usability studies that showed how 
 > blind users doing image navigation. When I tried to use a screen reader 
 > myself, I found myself typically reading the whole page and jumping 
 > forward a paragraph, or to the next header, or to the next link, but never 
 > navigating using images. I don't know why users would do this.)
 > 
 > Normally an image would have alternative text, but for images that fall 
 > into the cases above, all we have is a category and a title. The title is 
 > what would be really helpful for orientation, since one could, e.g., have 
 > multiple webcams on a page. Thus, for this kind of use case it seems that 
 > always providing an image title in the title="" attribute whenever the 
 > alt="" attribute is omitted would work. Sadly, in many cases site authors 
 > don't want to have tooltips show up, so we can't do that.
 > 
 > We could argue that such images must always be in links (e.g. pointing to 
 > the image itself) or in <figure> elements with <legend>s (thus giving a 
 > caption, and thus a context, to the image) but it's easy to come up with 
 > scenarios where that would be not what an author would really want. We 
 > don't want to use a brief category in the alt="" attribute here either, at 
 > least not without some indicator to go with it, because then that would 
 > hurt the usability of these pages in text browsers (where the whole idea 
 > is to replace the images with their replacement text and just pretend 
 > there is no image).
 > 
 > Given the lackluster reasoning behind having _category_ information, I 
 > don't think we can actually argue that including the information is a 
 > requirement, regardless of the syntax. Incidentally, this equally applies 
 > to when alternative text _is_ available, so I don't really see what 
 > problem is being solved by the idea of describing the image category for 
 > images with alternative text. (But, if categorising images is something 
 > that people believe would be useful anyway, I would encourage them to 
 > define a set of classes for the <img> element that declare the image type, 
 > e.g. class=photo, class=diagram, and so forth. If people want a wiki page 
 > to document this they should feel welcome to use the WHATWG wiki.)
 > 
 > 
 > Basically every proposal listed above (A-E and all the variants) have 
 > pretty serious problems. We can't require that every image have non-empty 
 > alt, because there are images that do nothing to help image-free users 
 > (A). We can't say that making a site like Flickr requires asking all users 
 > for alternative text, since users simply won't provide that data (B, B.1). 
 > We can't just omit alt="" with nothing else, since then users of image 
 > navigation will get lost (B.2.i). We can't use special syntax, since it 
 > hurts sites that care about accessibility more than anyone else, which 
 > just hurts the accessibility cause (B.2.ii.a, B.2.ii.b, B.2.ii.c). We 
 > can't introduce a new attribute because this will legitimise omitting alt 
 > far too much, again hurting the accessibility cause, and any new attribute 
 > will likely be misused to the point of making the attribute useless, due 
 > to the copy-paste mentality of authors who don't understand the spec 
 > (B.2.iii.a, B.2.iii.b, .2.iii.c.I, B.2.iii.c.II, B.2.iii.c.III). We can't 
 > just use alt="" with captions instead of replacement text, as that would 
 > both give a mixed message for authors, reducing the quality of alternative 
 > text in general, and would make it harder to understand pages with a lot 
 > of images even if they used alt="" correctly, if they sometimes had to use 
 > this technique (B.2.iv). We can't require that all such images be links or 
 > be in a <figure>, since both of these over-constrain the author and will 
 > likely just be requirements that are ignored (B.2.v, B.2.vi). We don't 
 > want to have multiple levels of conformance because authors seem happy to 
 > aim for the lower level (as seen with HTML4 Transitional), and because 
 > just doing this still doesn't address the problem (we have to pick one of 
 > the other solutions for the "lesser" conformance class), and because this 
 > isn't necessarily something that is fixable (we want full conformance to 
 > be something that authors can always aim for) (B.3). We don't want to just 
 > say authors can punt on alternative text altogether, as that doesn't help 
 > accessibility (C). We don't want to not require alternative text at all, 
 > since in most cases alternative text is quite easy to add and massively 
 > helps non-image users (D). We don't want to ban alternative text as there 
 > is simply no other alternative for handling images these days (E).
 > 
 > So. We need another option.
 > 
 > Are there cases where the image is lacking good alt text that wouldn't be 
 > covered by one of the following?:
 > 
 >  - title="" attribute on the <img> itself
 >  - <legend> of the <figure> that contains the <img>
 >  - heading of the section that contains the <img>
 > 
 > F. We could say that for these "key content without alt text" cases, we 
 > have the alt="" attribute omitted, but there must be at least one of the 
 > above, and the first of the above that is present must include sufficient 
 > information to orient the user.
 > 
 > 
 > On Sat, 16 Aug 2008, Steven Faulkner wrote:
 > > 
 > > It would be useful to have some real world use cases clarified in 
 > > respect to the changes:
 > > 
 > > 1. When a user uploads an image in flickr (http://www.flickr.com) they 
 > > are given the opportunity to provide a 'description', if they choose to 
 > > provide a description it is placed into the alt attribute of the image 
 > > (plus ' by xxxx').
 > >
 > > Is this conforming in HTML5? if not what would be an appropriate alt 
 > > attribute content if no 'real alternative text' is available?
 > > 
 > > example from flickr with description (the image is of a man on a bike):
 > > <img src="DSCF4330.jpg" alt="hubris is a curse by emispos">
 > 
 > It seems redundant to me, given that the title and the author have already 
 > been given by that point on the page. It would be reasonable text for a 
 > title="" attribute, maybe.
 > 
 > I would recommend not having an alt="" at all in this case, though I'm 
 > sure you disagree with that suggestion on principle.
 > 
 > 
 > > 2. When a user uploads an image in flickr (http://www.flickr.com) If a 
 > > user does not provide a description the filename of the image (minus the 
 > > file extension, plus 'by xxxx') if is used as the alt attribute content.
 > >
 > > Is this conforming in HTML5? if not what would be an appropriate alt 
 > > attribute content if no 'real alternative text' is available.
 > >
 > > example from flickr:
 > > <img src="DSCF4330.jpg" alt="DSCF4330 by emispos">
 > 
 > I doubt the file name is ever useful, and it probably hurts accessibility 
 > because of it. But in general my answer would be as above. Put this value 
 > in the title="" attribute and don't have an alt="" attribute. UAs and TAs 
 > in particular should indicate that this is an image and give its title="" 
 > attribute's value as its title, and not replace the image with the alt="" 
 > text wholesale.
 > 
 > 
 > > 3. on lolcats (http://icanhascheezburger.com/) users can add text to an 
 > > image, if the text the user added to the image were used as the content 
 > > of the alt attribute would that be conforming in HTML5? If not what 
 > > would be an appropriate alt attribute content if no 'real alternative 
 > > text' is available?
 > 
 > This is equivalent to the other cases, IMHO.
 > 
 > 
 > On Sat, 16 Aug 2008, James Graham wrote:
 > > 
 > > Arguably one could say that a title is not a text equivalent but users 
 > > would be best served if UAs use @title in a manner similar to @alt if no 
 > > alt text is available (with freedom to do something like say "image 
 > > entitled foo" rather than just "foo"). The argument against that is that 
 > > the title is already available inline so requiring the UA to present it 
 > > twice wouldn't help anyone.
 > 
 > Agreed.
 > 
 > 
 > On Sun, 17 Aug 2008, Steven Faulkner wrote to James:
 > > 
 > > As you are unsure about what the spec prescribes, as am I, it would be 
 > > very useful to get a ruling from the editor on how he intends the spec 
 > > to be interpreted in such 'real world' cases.
 > 
 > James' interpretation of what I wrote is exactly what I intended.
 > 
 > 
 > On Mon, 18 Aug 2008, Maciej Stachowiak wrote:
 > > On Aug 18, 2008, at 6:37 AM, David Poehlman wrote:
 > > > 
 > > > adding provisions for access to many many public facilities was not 
 > > > easy to meet either, but it became law and everyone benefits except 
 > > > those who didn't want the disabled in.
 > > 
 > > That's right, *public* facilities. Note that it is not legally mandated 
 > > that every private dwelling must be made accessible, or that every 
 > > handmade poster placed on a public bulletin board must have braille or 
 > > audio equivalents. That is because the focus of accessibility law, and 
 > > of our moral intuitions about the topic, is on public accommodations 
 > > provided by institutions, not private actions of individuals.
 > > 
 > > Flickr is one of many public sites featuring user-generated content that 
 > > is mostly shared with friends and family, but which is mostly visible to 
 > > the general public. In terms of our moral sensibilities about 
 > > accessibility, it is more like a public bulletin board where anyone can 
 > > put up a poster, than like the professional signage in a store or 
 > > school.
 > 
 > To make a decision on this <img> issue I also have to make some ethical 
 > determinations. In particular there is a conflict between allowing any 
 > author to publish content, and requiring all authors to publish content 
 > that is usable by anyone. I believe a middle-of-the-road approach is best 
 > here, allowing most authors to write content but only if they can provide 
 > alternative text for their images, while not requiring the effort to 
 > create such alternative text to be so great as to take a disproportional 
 > amount of time and thus not requiring all authors to publish content that 
 > is usable by anyone. This is similar to how HTML5 doesn't require all 
 > content to be written to be understandable by 3 year olds or dogs.
 > 
 > 
 > On Mon, 18 Aug 2008, David Poehlman wrote:
 > >
 > > accessibility is right not privilige.
 > 
 > Nope, sorry, accessibility is a privilege. Indeed, _not_ providing 
 > accessible markup is a human right (freedom of opinion and expression, 
 > UDHR article 19). On Tue, 19 Aug 2008, Smylers wrote:
 > 
 > 
 > On Mon, 18 Aug 2008, John Foliot wrote:
 > > 
 > > Eric has it almost right.  However, as I read the current Draft, there is no
 > > specific requirement for these attributes to be present (in the absence of
 > > appropriate @alt values) to be conformant.  While the draft offers us:
 > > 
 > >   <figure>
 > >   <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
 > >   <legend>Bubbles traveled everywhere with us.</legend>
 > >   </figure>
 > > 
 > > It is unclear however whether: 
 > > 
 > >   <figure>
 > >   <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
 > >   <legend></legend>
 > >   </figure>
 > > 
 > > ...would be conformant, as well as:
 > > 
 > >   <figure>
 > >   <img src="1100670787_6a7c664aef.jpg" alt="{photo}">
 > >   </figure>
 > > 
 > > I suspect that most accessibility advocates could accept the first instance
 > > (I have in principle), however the second and third instances are
 > > effectively useless and should not be deemed conformant.  I do not see this
 > > specificity in the draft spec, my only real issue at this time.
 > 
 > If we use the proposal above (F), then the second and third above would 
 > not be conforming.
 > 
 > 
 > On Fri, 22 Aug 2008, Al Gilman wrote:
 > > 
 > > If the agent putting the markup together really doesn't have a clue (not 
 > > the Flickr case) then I don't really have a problem with it being absent 
 > > and non-conforming.
 > 
 > By definition if it is non-conforming we are saying we have a problem with 
 > it. Sites aren't allowed to make non-conforming pages, that's what 
 > conformance means.
 > 
 > 
 > > In Ian's favorite case (not successfully isolated by the rule in the 
 > > draft) of a page with one photo on it (the only <img>? not likely) and 
 > > all about that photo, I would consider a 'nonce' text alternate of 
 > > @alt='the photo' would be pretty good. And under these circumstances a 
 > > null alt of @alt="" wouldn't be too bad.  Of course an @aria-labelledby 
 > > pointing to the page title which holds "what might have been a figure 
 > > legend but isn't" would be better.
 > 
 > So would the proposed solution above (F), where there is an implicit 
 > "labelledby" association, also be ok?
 > 
 > 
 > On Sat, 23 Aug 2008, Leif Halvard Silli wrote:
 > > > 
 > > >  * Introducing attributes for features that are supposed to be an 
 > > > indicator of a problem (lack of alt text, in this case) isn't good 
 > > > language design, as it brings it too much into prominence.
 > > 
 > > I don't see "lack of alt text" as "an indicator of a problem". But if we 
 > > introduced @role, /then/ @alt would be come an indicator.
 > > 
 > > Today, whether you write alt="" or alt="spacer", there is nothing which 
 > > indicates any problem. Both could be wrong. Both validate.
 > 
 > What I meant was that there is a problem (an image lacking suitable 
 > replacement text) and that we are looking for a way to tell the user agent 
 > that this problem exists. Further I was saying that we don't want to make 
 > it obvious that there is a way to indicate this problem, since that might 
 > encourage people to not include alternative text and just say "well I said 
 > that I didn't provide it so it's ok".
 > 
 > 
 > > >  * An attribute would almost certainly be copied around 
 > > > unintentionally by authors leading to it being at least as unreliable 
 > > > as the special syntax if not more.
 > > 
 > > Should we anticipate1 that the role of a particular photo will change 
 > > much and often depending on its context?
 > > 
 > > For the photo website use case, I have proposed role="albumphoto".  I do 
 > > not think it would hurt much if that attribute would follow by if the 
 > > image was copied to another context. Instead, it could help. There are a 
 > > bunch of other possible @role-s which probably would work in many 
 > > contexts: role=spacer, role=decor, role=potrait, role=mathexpression, 
 > > role=text etc.
 > > 
 > > Of course, an author should try to ensure he uses right role. But the 
 > > danger of copy-pasting seems exaggerated in this case.
 > 
 > Copy-and-paste is how massive amounts of the Web have come to be. People 
 > see something on one page, and misunderstand what it is for, and put it on 
 > their site even when they should not. e.g. we have many pages with <br 
 > xmlns=""> and <p/> and all kinds of crazy syntax.
 > 
 > 
 > > >  * An attribute introduces a whole class of extra conformance errors 
 > > > and complications, such as what to do when it is used with or without 
 > > > the alt="" attribute.
 > > 
 > > I actually thought we were /looking/ for ways to do better validation - 
 > > that's how I have understood Henri. Without @role, a validator cannot 
 > > check much more than whether @alt is or isn't there.
 > 
 > The point is that even with role, the validator still doesn't know 
 > anything, since the role could be wrong. It just increases the number of 
 > possible things that could be wrong.
 > 
 > 
 > Anyway, categorising seems of limited use, as noted in detail above.
 > 
 > 
 > On Sat, 23 Aug 2008, Philip TAYLOR wrote:
 > > Ian Hickson wrote:
 > > 
 > > > Speaking with my Google hat on for just this paragraph, I can assure 
 > > > you that with Picasa Web Albums, if we offered our users the 
 > > > opportunity to specify alternative text, most wouldn't use it, if we 
 > > > required them to provide it, most would provide bogus text, and if we 
 > > > forced them to provide useful alternative text, they would all find 
 > > > one of our competitors' sites and give up on Picasa altogether. 
 > > > (Google hat off.)
 > > 
 > > Speaking with my Picasaweb user's hat on, can you please substantiate 
 > > this statement with /evidence/, not hypothesis and personal (or 
 > > corporate) opinion? I can state with 100% certainty that I not only 
 > > /want/ to add ALT text, I /need/ to be able to, in order that others 
 > > (not necessarily sighted) can have equal access to my portfolios.
 > 
 > We should probably offer alternative text as an option, I was just saying 
 > that we couldn't _require_ it from all users.
 > 
 > 
 > > > In practice, photo sharing sites will never have alternative text 
 > > > available for the vast majorty of their images. Pretending otherwise 
 > > > is neither realistic nor productive.
 > > 
 > > Awaiting substantiation.
 > 
 > If you honestly think that there is any way that image upload sites will 
 > ever have suitable replacement text for the majority of their images, then 
 > I don't know what to tell you. It just won't happen.
 > 
 > 
 > On Sat, 23 Aug 2008, David Poehlman wrote:
 > >
 > > speaking as a blind user.  I would not put up a photo with out an alt 
 > > equiv.
 > 
 > How could you possibly know what the image is enough to be able to provide 
 > replacement text? I'm honestly curious. I've spoken to other blind users 
 > about this and gotten quite different responses, like "my alt='' text is 
 > always bogus! how am i supposed to know what the images are?".
 > 
 > 
 > On Sat, 23 Aug 2008, David Poehlman wrote:
 > >
 > > anytime you require the empty string, it is ambiguous.  If it can be 
 > > seen visually, it must be reflected textually.  The image is there for a 
 > > reason and that needs to be addressed.
 > 
 > This seems to deny the existence of purely decorative images, which seems 
 > like an unusual position. When a restaurant has a picture hanging on the 
 > wall, do you require the restaurant to describe the image to you, or is 
 > the image of no consequence to you?
 > 
 > 
 > On Sat, 23 Aug 2008, Leif Halvard Silli wrote:
 > > 
 > > A Solomonic solution:
 > > 
 > > 	Hide the very image if a valid @alt is lacking.
 > > 	Hide the @alt text if a valid src="" URI is lacking.
 > > 
 > > Note: all UAs, including Screen Readers, must conform!! ;-)
 > 
 > This would only result in us being ignored by implementors.
 > 
 > 
 > CONCLUSION:
 > 
 > I've put proposal F into the spec.
 > 
 > I've based this on as much objective data as possible, as described above. 
 > If people disagree with this, I would like to encouarge them to please 
 > provide actual data to back up their opinion. Repeating arguments that 
 > have already been put forth isn't going to change anything, since those 
 > arguments have all been considered already (I have read every single 
 > e-mail on the subject sent so far, and spent hours painstakingly 
 > considering every option I could). W3C HTML WG members who think that the 
 > current proposal is again unacceptable, but who do not have new 
 > information or arguments to put forward (i.e. who already know that I 
 > disagree with their reasoning) are encouraged to take this up with the 
 > HTMLWG chairs directly.
 > 
 > If people do want to do actual research here, I would love to see more 
 > usability study videos of blind users using the Web without guidance, to 
 > see how they actually interact with images. I think that that is the level 
 > of research we need to really make more informed decisions.
 > 
 > -- 
 > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
 > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
 > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'