- From: Leif Halvard Silli <lhs@malform.no>
- Date: Thu, 30 Aug 2007 05:03:51 +0200
- 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 […] 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: 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. 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