Re: Investigating the proposed alt attribute recommendations in HTML 5

On 2007-08-30 07:25:33 +0200 Maciej Stachowiak <mjs@apple.com>:
> On Aug 29, 2007, at 8:03 PM, Leif Halvard Silli wrote:
>> 2007-08-30 02:38:28 +0200 Maciej Stachowiak <mjs@apple.com>:

>>>> 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 am surprised to hear that you are in doubt […]
>
> 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.

OK, <div title="description">Text <img> <img> <img></div> is not the same case as the <a><img></a> case. But it doesn't need to be wrong to associate the DIV-title, I think. We could not agree that class names could be used for semantics. But title= have semantic implications. 
 
>>>>> http://www.flickr.com/photos/11994078@N04/

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

>> As we agree that that Flickr page was a bad example, […]

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

Looking in detail at things helps us solve real problems.

So, a better way for marking up album pages - pages with more than one "critical content" photos, then? The section of HTML5 we are debating takes «photo gallery, where a user has uploaded 3000 photos» as example of when ALT possibly could be deleted. Your remark here gets me to think that «3000 photos» is less relevant than the structure of the photogallery page. But I think HTML5 gives litle advice on how to do this better. You mention the FIGURE element (below). And this is also used in HTML5. But this is just for single images in a paragraph - not for 3000 images. 

These Flickr pages tells me we need a way to present a group of images - an album page. I imagine, that if I were a blind user, then I would like to know whether I should look at a particular bunch of images or not. Then it would be nice to know where, inside that page, the image collection is located.

Perhaps Flickr is doing something right by using TABLE for this.  But they need to add SUMMARY= to the TABLE, so that the photocollection can be identified.  (And of course not place image and image heading in different cells or in cells without any heaader-cell/data-cell association.) 

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

FIGURE is defined as a paragraph element, and can only have one piece of embedded content. As such, it can be inside a TD-element. As HTML5 propose that a TD can not contain both inline and block elements side by side, using FIGURE puts restricions on what TD can contain. (But, that is perhaps OK.)

FIGURE has LEGEND. LEGEND would pretty much play the same role as SUMMARY in TABLE=, I think.
 
>> 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?

My example above was not from a photo sharing site. Provided you think about using FIGURE with a LEGEND, then perhaps just «photo» could work as minimum solution? But we need to think about how, eventually, FIGURE should be parsed by AT UAs. 

Btw, FIGURE seems to have many similarities with OBJECT - and if the debate is whether we should make OBJECT better or introduce VIDEO, AUDIO etc, then perhpas we need to have the same debate about FIGURE/OBJECT?

[…]
>>> 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.

A kind of default alt text? Perhaps that could work for the FIGURE element when it contains IMG as embedded content _and_ a LEGEND.

If we can get JAWS to just say IMAGE by specifying this, would you then also specify, in HTML5, a list of translations of "Image" in all world languages - and have JAWS say it in the appropriate language?

But what if the FIGURE has a TITLE= attribute?
 
>>> 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.

So, could this make you more positve towards summary= given its possible usecase in photo collections?
-- 
leif halvard silli

Received on Thursday, 30 August 2007 22:27:17 UTC