Re: Adaptive Image Element Proposal

On Aug 30, 2012, at 1:10 PM, Adrian Roselli wrote:

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

Speaking at least for myself, this is the case. It may be a bit redundant to specify the `alt` attribute twice, but it seems to me that this is the path of least resistance in terms of authorship—leading to a better overall experience for users on assistive technologies. 

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

I agree. Now, likewise, I see no reason why `aria-labelledby` couldn’t be used here, but I’m not convinced we should make it a requirement. If `aria-labelledby` pointed at `picture` doesn’t work outside of browsers that natively support `picture`, we’ve painted ourselves into a corner—the fallback `img` won’t be able to reference it. Even if this isn’t the case, we’d still be limiting the accessible text to browsing contexts that support `aria-labelledby` — and speaking as an author (and one comfortable and familiar with ARIA attributes), I’m not convinced that this is the more intuitive option. It might be best to open that question up to the RICG before we make any decisions on that basis. I certainly don’t claim to speak for everyone!

Likewise, I’m unsure as to whether an `aria-labelledby` attribute on `picture` pointing at the fallback `img` will be able to access that value in browsers that do support `picture` and don’t receive the fallback. I’ll defer to someone more knowledgeable than I here, but that case does seem a lot more likely.

If that’s a viable approach, would it make sense to specify that the UA should ( given the absence of an `alt` attribute on the `picture` element ) defer to the fallback content for the `alt` by default? Else, if everyone feels that decision is better left to authors, would it be possible to specify that either approach is valid: either specifying an identical `alt` attribute on both `picture` and the fallback `img`, or though the use of `aria-labelledby`?

Received on Thursday, 30 August 2012 18:34:50 UTC