RE: Adaptive Image Element Proposal

Adrian Roselli, Sun, 9 Sep 2012 13:24:38 +0000:
>> From: Leif Halvard Silli

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

> This is the part where I have to defer.  [...]

I have now tested in JAWS: As I had assumed, it did work fine there.

> Having run through your test pages (on my netbook using Firefox and 
> Opera, but that's it since my test machines aren't here), I can see 
> the missing @longdesc option in the context menu.

Thanks for confirming test 1.
http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/test1

> I am resistant to proposing a polyfill when there is a pure-HTML 
> solution/option available. I don't know that there is yet  [...]

See what I said about JAWS above. However, the question is: Is it 
acceptable that @longdesc works worse inside <picture> than outside 
<picture>? (Namely, that it does not work in Opera, iCab etc unless one 
hacks/polyfills support (see below).)

> I do see that the menu (re)appears in your second example.

Thanks for conforming test 2:
http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc#test2

>> 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.
> 
> I am not against combining solutions, but again I am a little out of 
> my arena and don't feel I can give an educated opinion on that (yet).

In Firefox, if you do the following, then the link will be presented as 
a longdesc link:

   <img src=f alt=Text aria-describedby=link>
   <a hidden="" href=bar id=link >Txt</a>

If one add @longdesc as well, then both are covered. (But so far this 
technique doesn't really extend the support in anyway, as the only 
browser that offers this behavior also works with @longdesc.)

>> 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>
> 
> I am back to my prior argument that text inside a <picture>, outside 
> of an attribute, delivers content to users that don't need/want it. 
> Whether it's a link, a <desc>, or a <span>, it's still extra content. 
> Now, the link you suggest at least addresses the issue with pushing 
> too much content and also with the issue of being able to re-use 
> content. I do like that if we are in a position where an attribute 
> just can't work.

An detail regarding a <desc> is whether it was Laura's intention that 
one should be able to do this - note the <p>:

  <p>
    <picture>
     <img alt=photo src=foo >
     <desc>
       <table>a big table</table>
    </desc>
   </picture>
  </p>

If we ignore the <desc>, the -  provided we can assume that <picture> 
would operate like <video> does -  the <table> would, in the DOM, be 
pushed outside <picture>. 

I just say this to, once again, point out that HTML5 has some "parsing 
peculiarities" that would/should naturally prevent many authors from 
adding too much long fallback inside <picture>. Authors could 
circumvent this peculiarity by replacing the <span> with a <div> so it 
is just a "mild" way to make them do the right thing.

> Before I believe we are at that point, I'd like to hear more from 
> others who use AT and/or work with those who do. While I work with 
> many who do, I am only one perspective on this.

The role of VoiceOver in our debate is, largely, as an example of one 
AT which doesn't support @longdesc. However, I tested my test page in 
VoiceOver for iPad this weekend. And then I noticed that the technique 
I use in that test page where I hide the content in elements, behind 
the <img>, does not work so well. For example, when I touch the image 
in test 2, then nothing is being read out to the user. This would have 
changed if I had included the alternative text inside attributes. 
Either inside the @alt or via @araia-label/-labelledby/-describedby.

I think I will sum up the accessibility situation like this: 

(A) If responsive images are implemented via a new <picture> element, 
then it is a pity to not take advantage of this element by allowing 
alternative text via mark-up in the fallback.

(B) But the <picture> model to a large part gets in the way if the 
intention *anyway* is to let the @alt and @longdesc of a child <img> 
element take care of the alternative text. If that is the intention, 
then - from an accessibility point of view - it seems to me that we 
would be better off going for an extension of the <img> element.
-- 
leif halvard silli

Received on Sunday, 9 September 2012 19:35:11 UTC