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

Images and alternative text

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 4 Aug 2008 08:16:43 +0000 (UTC)
To: "public-html@w3.org" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0808040201560.13400@hixie.dreamhostps.com>

On Sun, 4 May 2008, Philip Taylor wrote:
> > 
> > Actually it doesn't, really. The intent of the alt="" attribute is to 
> > provide text that can be used to completely replace the image, and 
> > thus there isn't necessarily a way to distinguish this:
> > 
> >    <p><img src="x.png" alt="External image"></p>
> > 
> > ...from this:
> > 
> >    <p>External image</p>
> > 
> > ...in user agents that don't support images. In particular, a user 
> > agent like Lynx wouldn't distinguish the two cases above, but would 
> > show the image in the following case in a distinct UA-styled manner:
> > 
> >    <p><img src="x.png"></p>
> 
> That behaviour is not the most useful for the user: even if the alt text 
> truly is an equivalent of the image and can completely replace it in the 
> page, the user may want to save the image to disk so they can look at it 
> later or upload it to their own site, or copy the URI to a friend who 
> has a graphical UA, or activate their UA's advanced image analysis 
> feature to get a detailed description (e.g. to find out the colours in a 
> company's logo via an <img src="logo.png" alt="Megacorp Inc">).

Realistically, these seem like esoteric use cases. I'm sure user agents 
should provide user interface features to enable all images to be 
accessed, and so forth, but that doesn't mean that when an image isn't 
displayed and the image is really just conveying something like a header 
or an attribute of a product or whatever, that the image itself is going 
to be of any interest to the user.


> Those cases require the UA to inform the user that there is an image and 
> let the user select it so they can enter commands (to download, or to 
> copy the URI, etc), regardless of whether there is alt text. <img 
> alt=...> mustn't be treated as equivalent to plain text, else this 
> functionality would be lost.

It's not like users are browsing Web sites and, upon hearing that the logo 
is visible, suddenly interested in e-mailing the image to their friends or 
whatever. Users are, by and large, task-driven. If they want to look at a 
company's logo, they'll go out of their way to look for it; most of the 
time, the logo is only useful in indicating that the user is at the right 
site, and the company name is as useful for that purpose.


On Mon, 5 May 2008, Ian Hickson wrote:
> 
> It may be possible that the existing large amount of bogus missing-alt 
> content makes the user agent processing I'm advocating here impractical.

Further research has indicated that this is the case.

I have changed the spec to cater to the case of images whose content is 
unknown by saying that in such cases the type of image should be given as 
the alt text, with curly braces on either side. (Research has indicated 
that this pattern is rather rare, so it shouldn't really affect many 
pages, relatively speaking.)

User agents are required to clearly indicate an image is present when the 
alt text uses this pattern.


On Mon, 5 May 2008, Smylers wrote:
> 
> Elsewhere in this thread I've just written [about <figure><img>]:
> > 
> > That a <legend> is being used isn't the salient point; what matters is 
> > whether any visible text on the page (whether in a <legend>, a <p>, or 
> > whatever) is already a textual alternative of the image.  In that case 
> > alt="" is mandated, to clearly indicate that no information is 
> > missing.
> 
> However I find that somewhat unsatisfactory.  Suppose I'm browsing
> image-lessly (perhaps I'm on a train with a low-bandwidth connection)
> but can choose to view particular images (maybe I'm using 'Lynx' in X,
> where a selected image can be opened with an external image viewer);
> consider this example from the spec:
> 
>   A graph that repeats the previous paragraph in graphical form:
> 
>   <p>According to a study covering several billion pages,
>   about 62% of documents on the Web in 2007 triggered the Quirks
>   rendering mode of Web browsers, about 30% triggered the Almost
>   Standards mode, and about 9% triggered the Standards mode.</p>
>   <p><img src="rendering-mode-pie-chart.png" alt=""></p>
> 
> I might appreciate seeing that pie chart.  However as the spec currently 
> stands I can't know about its existence, so I can't choose to open it in 
> an image viewer.

I've added "User agents may provide the user with a notification that an 
image is present but has been omitted from the rendering." for this case.


On Thu, 8 May 2008, Steven Faulkner wrote:
> 
> The first draft of our rewrite of major sections of 3.12.2 "The img 
> element" in the HTML5 draft is now available:
> 
> http://www.paciellogroup.com/blog/misc/uc/

I've added a CAPTCHA example to the spec. As far as I can tell, the spec 
already covered every other relevant topic mentioned in the proposed text.


On Tue, 13 May 2008, Andrew Sidwell wrote:
> 
> I would be happy if someone (or several someones) in favour of making 
> alt mandatory in all cases would answer very simply: How does a blind 
> photographer mark up a photo, which is known to be critical content, but 
> which she herself cannot describe?
> 
> Is it:
> <img src="photo">
> <img src="photo" alt="Photo">
> <img src="photo" alt="Exposure 2s, f/12">
> or something else?

At the moment, it would be something like:

   <img src="photo" alt="{Photo}" title="Exposure 2s, f/12"


On Tue, 13 May 2008, Katie Haritos-Shea wrote:
> 
> [Jane] is blind photohrapher. Jane is spending the day with her 5 year 
> old granddaughter, Trina, in Washington DC. Jane lives in Austin, Texas.
> 
> Jane wishes to share the photos of her day she spent with Trina with her 
> sighted hushand, Tom, back in Austin (or her family, or her friend 
> network).
> 
> [various scenarios, all ending up with Jane outputting alternative text 
> like the following]
>
> <img src="Trina-Jane_2009-4-1.jpg" alt="Trina and Jane in Trina's 
> playroom, April Fools Day 2009">

That's a caption, though, it's not alternative text. I mean, if Tom lost 
his vision while Jane was away, getting a photo whose alternative text is 
"Trina and Jane in Trina's playroom, April Fools Day 2009" wouldn't help 
him at all. Good alternative text for such a photo would give vivid detail 
describing Trina's facial expression, how she was interacting with Jane, 
who else was in the room, what toys she had, and so forth.

Indeed, "Trina and Jane in Trina's playroom, April Fools Day 2009" is a 
caption, not a replacement for the image. Even a sighted reader would want 
to see this text -- consider Jane's friend Max, part of her friend 
network, who has never met Trina. He would want to know who was in the 
photo, where it was taken, and when it was taken. The photo itself 
wouldn't tell him that, and since he can see the image, the alternative 
text wouldn't be visible to him.

Right now, the spec actually says that what should happen is something 
like:

   <img src="Trina-Jane_2009-4-1.jpg" alt="{photo}" title="Trina and Jane 
   in Trina's playroom, April Fools Day 2009">

...or:

   <figure>
    <img src="Trina-Jane_2009-4-1.jpg" alt="{photo}">
    <legend>Trina and Jane in Trina's playroom, April Fools Day 
    2009</legend>
   </figure>

...or:

   <h1>Trina and Jane in Trina's playroom, April Fools Day 2009</h1>
   <img src="Trina-Jane_2009-4-1.jpg" alt="{photo}">


On Mon, 26 May 2008, John Foliot wrote:
> 
> Given that "photo sharing" is one of the most popular activities on the 
> internet, all the more reason to not leave open the door that suggests 
> that sometimes an image without @alt is "conformant". The constant 
> refrain from the working group is that this would be a rare instance, 
> yet you now suggest that it will be the majority, and not a rare 
> instance at all.  If 10 of the top 100 websites on the WWW have this 
> magic get-out-of-jail-free card then surely others will seek to claim 
> the same status.  The precedent being suggested here is staggering.  
> This is supposed to "help" accessibility?

There is no way that we are going to convince the users of these sites to 
actually provide useful replacement text for their images.

So whatever we do, the accessibility story of photo sharing sites is going 
to be rather poor.


> Exactly!!  What unintended consequences and second-order effects do you 
> think will emerge once you make @alt optional for a class of sites that 
> claim "special status"?  One possible outcome will be that more sites 
> will seek to claim this status, and the overall quantity of images with 
> @alt will diminish.

The spec still gives these sites special status, but does so using a new 
syntax instead of allowing alt="" to be omitted. I don't think this makes 
any difference to the issue you raise though. I don't see any way to 
address this issue. Simply making it invalid for those sites to use HTML 
isn't an option.


On Tue, 27 May 2008, L. David Baron wrote:
> 
> Would you agree that something like alt="[PHOTO]" or alt="[IMAGE]" would 
> be better for users in that case than alt=""?
> 
> If so, would you agree that it's worth standardizing what should be used 
> to mark such a case rather than having authors pick "[IMAGE]" or 
> "[PHOTO]" or their own variant?

I actually ended up using something similar to this, but based on the 
prevalence of various syntaxes, picked {} delimiters to be the indicator.


On Tue, 27 May 2008, John Foliot wrote:
> 
> Is introducing a new attribute [importantimage] better than sticking 
> with existing attributes and simply introducing new, reserved values?  

Reserved syntax is what I ended up using.


> (* Photo.  What if, instead it is an illustration, or a chart, or some 
> other form of iconic or visual marker?  Would a collection of reserved 
> values be appropriate here?)

It's an open-ended set, as currently defined.


On Tue, 27 May 2008, David Poehlman wrote:
>
> Neither "important image", "photo" chart" "diagram" or anything else 
> like these descriptions in alt tell me anything.  I suspect though that 
> they are meant to convey something useful to preprocessors and I dread 
> this.

I agree that they don't solve the problem. Unfortunately I don't think the 
problem (the image not having alternative text) is solvable -- the whole 
point here is that the image has no alternative text available.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 4 August 2008 17:45:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:21 GMT