- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Sun, 2 Sep 2012 06:51:30 +0200
- To: Peter Winnberg <peter.winnberg@gmail.com>
- Cc: Steve Faulkner <faulkner.steve@gmail.com>, Mathew Marquis <mat@matmarquis.com>, HTML WG <public-html@w3.org>, "public-respimg@w3.org" <public-respimg@w3.org>
Peter Winnberg, Sat, 1 Sep 2012 19:47:40 +0200: > 2012/8/31 Steve Faulkner: >> When and if <picture> becomes implemented in browsers then the text >> alternative can be provided as text in the sub dom: >> >> <picture> >> This is the text alternative >> <img alt=""> >> </picture> >> >> as I have previously mentioned I don't see what the problem is with doing >> the above now and visibly hiding the text using CSS. > But here are some problems that I see with the example that Steve sent > about how to provide the text as part of the sub dom and hiding it > using CSS. > > A user agent that supports HTML 2.0, but not CSS or ARIA would ignore > any CSS to hide the text alternative and will present the text > alternative even if it can load the image. HTML 2.0 browsers were not always able to show embedded images. So I would not say we are going backwards just because a HTML 2.0 browser would have displayed both the alternative text and the image, simultaneously. > A user agent that supports CSS but not the picture element would > always hide the text alternative (well depending on which media that > the CSS was specified for) even if the image cannot be loaded. This is true. (Though with CSS plus JavaScript, I managed to make fallback display when the image fails to load quite simply.) It is even *more* true if the UA *supports* the picture element. Quoting what Steve said: ]] i.e. the sub dom content is only visibly displayed in browsers that do not support canvas, [[ There was an idea floated in the CSS working group a while back, about a CSS selector that could select img elements where the image failed to load. Could be relevant in the picture context, no? So I agree: Steve should note this as an issue with the canvas-picture model that needs attention. > Also > because the image has an empty alt attribute it would be marked as > presentational. Let’s say that ARIA isn’t supported, then you cannot > define the relationship between the text alternative and the image > (and if you could, this could lead us into the reference hidden > content issue again). One conforming way to solve that problem, would to have a no-empty alt attribute. Just fill it with white space or similar. Or even a short text, like "Photo". But else: If <picture> were to follow the <canvas> model, then there did not need to be any <img> in the fallback. Thus, I am not certain that it is Steve's intention that the AT user knows that he/she "looks" (sic) at a picture ... Clarification and thought is needed. > But on the other hand, if the alt attribute on the img element is used > for the text alternative it would work in both of these cases. Even in > a user agent that only supports HTML 2.0. But then you lose the > ability to add structure to the text alternative. Nice summary. But I think the role of the img element in in a canvas inspired <picture> element needs clarification. Is it there in order to inform that, hey, this is an image? Or would the <picture> element take upon itself the role of announcing that it is an image/picture, on its own feet? Or isn't it very important - given how <canvas> works - that the user knows that is being presented a "picture"? -- leif halvard silli
Received on Sunday, 2 September 2012 04:52:02 UTC