RE: Adaptive Image Element Proposal

Adrian Roselli, Thu, 30 Aug 2012 15:30:41 +0000:
>> From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no]
>>> 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>

> My other thought
  [...]
> Is it fair to assume there are users who can benefit from @alt who 
> are using browsers that do not support <picture> and do not have any 
> ARIA-capable AT either?
>
> If not, then I am running at windmills. If so then I still believe 
> the redundancy is necessary.

Such users would be "left out", that is ture. However, please not the 
draft does not *require* the presence of an img element. And the 
simplest thing for authors would be to not include any img element. Do 
the users you have in mind get any benefit from an img element without 
alternative text? My answer is yes, they get to know that there is an 
important image there. Repetition is always something that cause 
authors to not due what is best for their users. It should be avoided.

We should keep in mind that the main reason authors will include an img 
child element will be in order to make sure the visual fallback works. 
From that point of view, we should make it as simple as possible for 
authors to provide accessible markup. May be the picture spec editors 
disagree with me - may be they consider that a duplicated alt attribute 
will be simpler, to all authors, always. Fair enough. However, from my 
point of view, this should be up to authors. And I therefore maintain 
this as something the editors should consider.

Now, regarding figure. For the record, a simple example of what I think 
should validate, due to the fact that it would have validated if you 
replaced the <picture> with a <img src=file> element:

 <figure>
  <ficaption>Caption</figcaption>
   <picture>
    <source src=files >
    <img src=file > 
   </picture>
 </figure>

> I had been staying up on the dropping of @alt on <img> for <meta 
> name="generator">, but had not followed along on <figcaption> 
> apparently. I am not in favor of dropping @alt from <img> in any 
> current scenario.

You must look the issue and eventually file a bug or support an 
existing bug/issue.

>> 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.
> 
> I suspect it is, if only to ease the reader's need to keep going back 
> and cross-referencing.

Agree.

>>>> (3) If the picture is presentational (has empty alt), then the img,
>>>> if any, would need to have empty alt as well.

>>> The spec says to match the value, and blank is still a value.

>> 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.
  [...]
> This is really a semantic discussion and I 
> think the wording is clear enough. Match values. Simple.

Well, since I suggest that it should be possible to drop the @alt and 
just let aria-labelledby point to the picture element, I already 
operate with a more complicated rule. So I maintain that this as a 
proposal to the picture element editors.

>>> This is where I wonder if @longdesc was ignored prematurely.
>> 
>> So, on which element would you have placed the @longdesc? [...]

>> <picture role="document">
>>   <source src="foo >
>>   <p> Markup goes here </p>
>> </picture>
> 
> On the <img>.

Where is the img element in the above example?
-- 
leif halvard silli

Received on Thursday, 30 August 2012 16:04:26 UTC