RE: Adaptive Image Element Proposal

Adrian Roselli, Thu, 30 Aug 2012 13:18:24 +0000:
> >> From: Leif Halvard Silli, Thursday, August 30, 2012 8:53 AM

>> <picture alt="Alernative text" id="pict" >
>>   <img src=file  aria-labelledby="pict"/>
>> </picture>

> IE 6-9  usage is not exactly zero, and IE10 may be out before this is 
> supported. In that case, the <img> element is the only thing that 
> will be recognized and so the redundancy is necessary.
> 
> The ARIA attribute is meaningless in that case since the browser 
> won't pull it from an element it doesn't know.

The premise of your conclusion seems wrong.

An ARIA supporting AT will pull the content from any element, known or 
unknown. The only issue is, thus, that IE6 to IE8 does not support 
new/uknown elements. However, even this should not be an issue since 
the alternative text is kept inside an attribute. So, e.g. IE6 to IE8 
would - due to their peculiarity - treat the above picture element like 
two elements:

<picture alt="Alernative text" id="pict" />
 <img src=file  aria-labelledby="pict"/>
</picture/>

Thus, as you can see, this should work. And I believe it does work, to 
the degree that ARIA works in the specific version of Windows. (It does 
work in XP, it seems, or at least AT which support ARIA do work on XP.) 
When it comes to IE9, however, then it does support unknown/new 
elements.

>> (2) Also, if the picture element is the content of an figure element
>> with a figcaption, then the img should not need to contain the alt
>> attribute. (This may not need to be said - perhaps HTML5 already
>> cover this.)
> 
> Again, this presumes the browser supports HTML5's <figure> and 
> <figcaption> element, which older browsers do not (and will not).

If you really believe this is bad, then you should file a bug against 
HTML5's permission to drop the alt attribute completely - omit it - 
when the img element is the sole content of a figure element which has 
a non-empty figcaption element. (Check what HTML5 says about use of alt 
for the img element.)

The question I ask - "perhaps HTML5 already cover this" - relates to 
whether it is necessary to say anything, in the spec. But it probably 
is.

>> (3) If the picture is presentational (has empty alt), then the img, 
>> if any, would need to have empty alt as well.
> 
> If I am reading this correctly, you want the spec to state that an 
> @alt value of blank should be repeated on the <img>. If so, the 
> wording already says that. The spec says to match the value, and 
> blank is still a value.

It says that one should repeat the @alt content in order to "fall back 
gracefully". As you know, presentational elements usually do not have 
fallback. Or, at least, it is common to think that they doen't. So I 
still think that the spec should point this out.

>> In bug 18384 [2], we discuss other ways to provide fallback. Perhaps
>> those methods should be reserved to situations when picture is given,
>> by the author, another role than "img" or "presentation" - e.g. if it 
>> has 'document' role. Thus, it may be necessary to specify further
>> rules about the fallback so that the fallback is not used in ways
>> which are inconsistent with its role as alternative text.
> 
> This is where I wonder if @longdesc was ignored prematurely.

So, on which element would you have placed the @longdesc? For the use 
case I had in mind, see the example below. Thus I think @longdesc is 
irrelevant. (Adding @longdesc to picture could in theory be relevant, 
though.) 

<picture role="document">
  <source src="foo >
  <p> Markup goes here </p>
</picture>
-- 
leif halvard silli

Received on Thursday, 30 August 2012 14:43:05 UTC