Re: Investigating the proposed alt attribute recommendations in HTML 5

On Aug 29, 2007, at 8:03 PM, Leif Halvard Silli wrote:

> 2007-08-30 02:38:28 +0200 Maciej Stachowiak <mjs@apple.com>:
>> OK.
>
>>> 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:

If the title is on the ancestor element, it's generally assumed that  
it is supplemental to the ancestor and everything it contains. If that  
happens to be a <div> element with a bunch of <img> elements contained  
inside, then using the title for the <div> as descriptive information  
for every image seems like it would be wrong. In this case it seems  
like it would be good, but I haven't studied enough examples if there  
is a good way to draw the boundary.

> Geez:
>>> […] JAWS only announces the image name as a last resort,
>>> after first looking for alternate text, or text from the title
>>> attribute. […]
>
> Maciej:
>> 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.

No, I meant that it seems like the markup could be improved so that  
JAWS would not have to resort to announcing the filename by moving the  
title to the img.

> 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?

As cited below, <http://www.flickr.com/photos/11994078@N04/1237874307/ 
 > would be such an image, but as you explained below it's not a great  
example due to the icons between the title and the actual image.

>>>> 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 ...)

flickr is a prominent example of a photosharing site. To the extent  
that it is a useful example, I think we should consider the content,  
not so much the exact markup they use today. The idea is to provide  
options in HTML5 that would allow their markup to be made even better  
while presenting the same content. For example, is there some way they  
could achieve the same basic layout, include all the same info, and  
not cause the image caption to be read twice when using a screen  
reader? That seems more fruitful to me than making a tweak or two to  
their markup to test what happens.

> 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.

Repetition might beat making the association unclear, but can we come  
up with markup that lets the association remain clear without the need  
for repetition? Using good HTML5 idioms, I think the <figure> element  
might be a good choice.

> 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».

Do you think that for a photo sharing site, "This is the photo that we  
are talking about" or other such prefab text would be an improvement  
on pages where the title is still present?

>>>
>>> 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

It seems good to consider that option as well. It would be nice if  
there was a way to get screenreaders to just say "Image" or something  
like that and let it be clear that this is the image described by the  
immediately preceding text, but it sounds like JAWS in the default  
configuration can at best either say nothing at all (empty alt) or  
read the image filename (no alt), both of which seem bad in this case.  
Part of the problem is the way the filename is read - reading it out  
as if it contains multidigit numbers seems like it could be extra  
aggravating.

>> 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.

Yes. But we should think about the best way to make good markup for an  
image gallery. There are lots of them on the web, and it would be nice  
to have a good markup option to recommend.

Regards,
Maciej

Received on Thursday, 30 August 2007 05:25:50 UTC