RE: Adaptive Image Element Proposal

Adrian Roselli, Fri, 7 Sep 2012 15:24:53 +0000:
>> From: Leif Halvard Silli:

>> Because it could impact on ISSUE-30, here are some data on whether
>> @longdesc on <img> would be ideal for <picture>. Let's start with an
>> example:
>> 
>> <picture>
>>   <img src=file alt=text longdesc=description.url > </picture>
>> 
>> QUESTION: How would users of the equipment listed on your
>>           research page access that longdesc?
>>   ANSWER: It would be broken in some of them. That is: Support
>>           would be worse, when used on an <img> inside <picture>
>>           compared with outside <picture>.
> 
> How do you know this?

 # First, I made the assumption that it would not work 
   in contextual menu based solutions.
 # Then I made a picture element for testing. [1] 
 # Then I tested that test element in iCab. 
   (Later, after your question, I also tested in
    in Opera.)

As for Laura's test page, then I have contributed to to. I'm not 
opposed to longdesc as such - and if @longdesc is permitted in HTML5, 
then it would also be permitted inside picture. So we should consider 
how it works, regardless.

>>       AT: ATs are *probably* more lucky, since they they tend to not
>>           rely on contextual menus. Perhaps e.g. Steve understand
>>           more on this problem?
> 
> Yeah, I would hope AT would be able to access it -- I am not an 
> expert user and cannot say either way.

Well, you should not take my sound reasoning for it any more than for 
contextual menu based solutions? I have not documented what I said ... 
But I believe it is entirely possible to clutter it up so it don't 
work. It only requires that the <img> is, in some way or another, 
hidden from AT. Some authors will probably err.

>> [*] http://csswizardry.com/2011/07/responsive-images-right-now/

>> 
>> This is as complex as anything else. But of course, on the good say: If one
>> manages to use that polyfil, then the <picture> should work as well 
>> as <img> does, both with regard to @alt and @longdesc.
> 
> I don't know this applies here. As far as I understand it, we want to 
> create a solution that doesn't need a polyfill. Discussing how a 
> polyfill does it is interesting in that it shows us how a workaround 
> functions today, but it doesn't do much except to let us know there 
> is still work to be done on this.

What doesn't apply? Polyfill? Well @longdesc without polyfill does not 
work for <picture> in browsers which support longdesc via a contextual 
menu. End of _that_ story, I think.

Mat's spec is based on a polyfill - which thus serves as a prototype. 
And, one it is important to think about whether the solution in the 
polyfill works compatibly - or different from - the end goal solution. 
Also, I try to be modest with regard to what to expect from vendors ...

But I replicated - and tested - the 'responsive–image-right-now' 
technique in my test page.[2] Thus you can verify that it works - for 
example by testing in Opera. From that point of view, it is a success. 
It really does work. But it does require a polyfill - just as the 
not-longdesc based solution do.

AND BY THE WAY: It would/could be possible to combine the solutions. 
E.g. one could use the @longdesc as polyfill, in conjunction with a 
fallback based solution. I think that authors should be permitted to 
provide the fallback via markup as long if they want and know how to do 
it.

>>>> Even @longdesc is very complex if you want to implement support for
>>>> it in AT which do not support it already.
>>> 
>>> Recent research finds that modern screen readers have good support for
>>> the longdesc attribute [1].
>> 
>> Yes, but the fact that NVDA and VoiceOver doesn't support it could be a
>> concern, to some. For these users, the long description would be hidden.
>> (But, once Firefox finalizes its VoiceOver support, then perhaps we 
>> will see it in VoiceOver? So far that is vapor ware, though.)
> 
> Yes, it could be a concern to those users. But those users are 
> already dealing with lack of @longdesc support. There is no reduced 
> functionality here as a result of this (for the NVDA/VO users)

Yeah, it would be a status quo solution. (Though, in honesty, if one 
wants, then one could help NVDA+Firefox to handle @longdesc with some 
aria-polyfill.)

> I am of the opinion that @longdesc exists and has support, even if 
> the support isn't ideal, and so is the natural long text alternative 
> content holder. There is already more support for @longdesc today 
> than there would be for a <desc> element (or the absence of an 
> element), particularly because the content of a <desc> element (or 
> not-element) will be forced on users on older browsers who don't want 
> or need it. Expecting authors to style that away without impacting 
> accessibility seems like a far reach here.

The alternative to @longdesc does not need to be Laura's <desc>. It 
could be a link:

  <picture>
    <img src=file alt="Photo." >
    <span>Short description.</span>
    <a href=longdesc>Link.</a>
 </picture>

[1] 
<http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/#test1>
[2] 
<http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/#test2>
-- 
leif halvard silli

Received on Friday, 7 September 2012 19:30:37 UTC