W3C home > Mailing lists > Public > public-html@w3.org > August 2008

Re: The alt="" attribute

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Tue, 26 Aug 2008 11:50:31 +0100
Message-ID: <55687cf80808260350q130cd904vee3358a26ee6f7aa@mail.gmail.com>
To: "Ian Hickson" <ian@hixie.ch>
Cc: public-html@w3.org

Hi Ian, On an initial read i think that the latest version of the spec
(in regards to alt) is a major improvement
on all that has gone before.

--
stevef

2008/8/26 Ian Hickson <ian@hixie.ch>:
>
> 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.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
with regards

Steve Faulkner
Technical Director - TPG Europe
Director - Web Accessibility Tools Consortium

www.paciellogroup.com | www.wat-c.org
Web Accessibility Toolbar -
http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Tuesday, 26 August 2008 10:51:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:57 UTC