- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 26 Aug 2008 08:17:49 +0000 (UTC)
- To: public-html@w3.org
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 26 August 2008 08:18:07 UTC