RE: Adaptive Image Element Proposal

> From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no]
> > 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
[...]
> > 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?
[...] 
> 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.

I feel that diligent authors who care about these issues will include an <img> as a fallback and will also be aware of the need for @alt and will be capable of copying the text into both of them. I doubt that will happen in all (or most) cases, sadly, so I agree that simplicity is important. However, making this a requirement for validation puts the onus on the developer and acts as a reminder to do his/her job.

Outside of human authors I see this is a simpler issue for WYSIWYG applications and generated HTML to handle -- just duplicate the @alt text that has been provided elsewhere (again, presuming the user has even provided it). Getting toolmakers to do that, however, I know from experience is an uphill battle, but is at least possible.


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

I think the spec authors don't have such an absolute view. I feel they chose the option most likely to be supported with the least confusion and pre-existing use cases. Authors can still decide to exclude it, they'll just be going against the spec.

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

Your example has not @alt anywhere. Trying to stay in the scope of the <picture> element proposal, I think it is missing two @alts.

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

Again, the <figure> one is new to me, though I appreciate your prodding to take action.

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

It is a bit more complicated. It also feels more complicated than the replicated @alt, which doesn't mean you can't use ARIA.

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

At the risk of circling back, I feel the <img> is missing (I had meant to "include" it in my response as an edit). To your point, it is not explicitly required, which I had not realized at my first reading.

And this is why I like these discussions -- I pick up bits I missed before.

Received on Thursday, 30 August 2012 17:10:57 UTC