W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2007

Re: Investigating the proposed alt attribute recommendations in HTML 5

From: Leif Halvard Silli <lhs@malform.no>
Date: Thu, 30 Aug 2007 05:03:51 +0200
Message-ID: <b84bba17d4e20247a37aaeb65bfe5f8b@10013.local>
To: Maciej Stachowiak <mjs@apple.com>
Cc: HTMLWG <public-html@w3.org>, wai-xtech@w3.org, Steven Faulkner <faulkner.steve@gmail.com>

2007-08-30 02:38:28 +0200 Maciej Stachowiak <mjs@apple.com>:
> On Aug 29, 2007, at 4:45 PM, Leif Halvard Silli wrote:
>> 2007-08-30 00:03:17 +0200 Maciej Stachowiak <mjs@apple.com> wrote:
>>> On Aug 29, 2007, at 11:48 AM, Steven Faulkner wrote:

>> The above page include TITLE= on the images. How[e]ver, I suppose what  you 
>> meant to say is that the Title= attrib[u]te isn't in the IMG  element itself, 
>> but only the surrounding A-element.
> No, […] I meant in the ordinary english sense, not the  markup  […]


>> However, «If this attribute is omitted from an element, then it  implies 
>> that the title attribute of the nearest ancestor with a  title attribute 
>> set is also relevant to this element.» (HTML5 on the  use of TITLE= [1])
> I'm not sure if it would be appropriate for screen readers to use an  
> ancestor title to identify the image. Maybe in this special case where  
> there's no other content inside the ancestor. Or perhaps they should  read 
> the title of a link that has no text content.

I am surprised to hear that you are in doubt about the usefulness of this. Actually, in your reply to Geez [1], you seemed to imply the opposite - but I was mistaken then:

>> […] JAWS only announces the image name as a last resort,
>> after first looking for alternate text, or text from the title
>> attribute. […]

> It looks like in the case of this page, there is a title="" attribute  on the 
> <a> element containing the image, but not on the <img> itself: 
> http://www.flickr.com/photos/tags/sleepingcats/

I thought you were hinting that JAWS could improve its «repair the content» behaviour by looking for the title of the A-link. Steve Faulkner in his test says that this is exactly the way that  Window Eyes works, and he describes the effect of it very positively: «So in the case of the example critical content the recommendation of omitting the alt attribute is negated as the the title text is the auto generated photo title..» [2]

>>> What about a page like this (I found it from the example you used),
>>> where the titles are included, and are duplicated by the alt text:
>>> http://www.flickr.com/photos/11994078@N04/
>> That is a questionable test page in this context. […]

>> (1) The IMG tags on that page does not have TITLE=. Instead it has 
>> captions.
>> (2) BUT, the captions are placed inside a H4-element, inside its own 
>> TD-cell. Whereas the the image is placed in the TD cell just below  this 
>> TD-cell, in the same column.
>> (3) The TD with the IMG does not have a HEADERS= attribute which  shows 
>> what its caption cell is. I have now clue how the H4-element  is linked to 
>> the image cell ...
>> May be the captions should have been in TH-cells ... Or, the best  would 
>> probably have been if the IMG and the caption was placed in  the same cell 
>> (if TABLE should be used at all).
> Good point. 

Thanks for the HEADERS= up ;-)

> Suppose however there were good markup that associated the  
> header with the image. In that case, is it helpful to have alt text  that 
> duplicates the text in the header?

You must, I think, provide more ifs: If the images had not been contained within A-elements - which very often _have_ a TITLE=, then, if the intended ALT= text is provided outside the IMG element, and if the ALT= text was just a repetition of the that text – do you have a good example page from out there?

>>> Based on what you said about JAWS, it sounds like alt="" might give
>>> the best results in that version of JAWS.
>> I don't think so.
> I meant because it would already read the exact same text from the  title in 
> the visible text (I'm using title to refer to the large  header text above 
> and caption to refer to the smaller text below,  perhaps there is better 
> terminology). It seems like reading the text  twice is unhelpful. But it may 
> be that the markup does not make it  easy to make the assiciation.

As we agree that that Flickr page was a bad example, any better examples? (It surprises me that all this talk about Flickr as a real world examples ends up with revealing that Flickr is not at all what we wanted ... Turns out that Flicker was a real world example just in the theory, then ...)

Reading the same text twice on different items can be helpfull sometimes - it helps as idenfication. If the association between the image and its title and its caption (the way you use those words) is clear - and the association should be quite clear if the title comes directly before and the caption just after (in the code/code semantics as well) - then, it could be boaring to read the same text twice. But it would probably be better to read the TITLE= twice (rather than caption/description), though, as the title-text probably was quite short.

If one finds that the image is adequately described in the surrounding text, then the image becomes kind of secondary to the textual content. And the HTML5 draft mentiones many examples were an empty alt="" is the best thing. But,if the images are «key content», then there should be something that identifies as such, I believe. It could be just a very short text or a word. Consider a text that describes and talks abotu Munch's «The scream», then if «The scream» image is in the text, it could e.g. have «This is the painting that we are talking about».
>> If we assume that JAWS can/could establish the relationship between  the 
>> caption and the image by applying its heuristics, then I think  these 
>> images could be described as buttons - as they are wrapped in  the 
>> A-element and because their title is given in the caption. The  relavant 
>> section in HTML5 is  «Icons: a short phrase or label with  an alternative 
>> graphical representation» [2]. As there is no other  text inside the 
>> A-element, the IMG must have alt text. But it should  have been only a 
>> short button-text.
> Although the image is clickable, I don't think icon is the intended  
> semantic. 

There are more than one purpose with these images. One of them is that you can scan those images to see if they are nice/interesting, and then click on the ones that you want to single out. They are links, and need link-text. Why would you want to look for a way to omit link text?

> But for comparison, how about this individual image page  that has 
> a visible caption and where the image is not a link: 
> <http://www.flickr.com/photos/11994078@N04/1237874307/ >. In this case the 
> page uses empty alt.

And it uses H1 as title of the image. Yet, it places an iconic image _with_ alt text _between_ the H1 element and the "critical content" image.
>> The ALT could have been empty if the caption had been kept inside  the 
>> A-element - together with the IMG. Then we could have omitted  the 
>> alt-text, according to HTML5: «In some cases, the icon is  supplemental to 
>> a text label conveying the same meaning. In those  cases, the alt attribute 
>> must be present but must be empty.»
>> But it also depends on how the page is intended to be read. All  images are 
>> buttons. But many readers would not be interested in  clicking on those 
>> "buttons" - they would be content with looking at  this page alone. If that 
>> is the intention, then the images should  have had full replacement texts, 
>> which described the content even  better than what the captions do.
> Sure, that would be nice. But if such text is unavailable, we need to  
> determine which of the following is best:
>   - alt attribute that duplicates the header
>   - empty alt attribute
>   - no alt attribute

I would like to add:

    - short meaningful/functional identifying text

> In general it seems that alt text which duplicates other text next to  the 
> image would be unhelpful, but in this case the page uses a layout  table in 
> an inaccessible way (no proper header/cell association) so it  might be hard 
> to associate the text with the image.

And by this, I suppose you mean to say that the alt text in this case surve the purpose of identication in the real world bad markup.

[1] <http://lists.w3.org/Archives/Public/public-html/2007Aug/1131.html>
[2] The «Notes:» under <http://www.paciellogroup.com/resources/articles/altinhtml5.html#jaws>
leif halvard silli
Received on Thursday, 30 August 2007 03:33:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 20 January 2023 19:58:27 UTC