Re: Adaptive Image Element Proposal

Laura Carlson, Thu, 6 Sep 2012 12:55:59 -0500:

>> Needless complexity: The complexity is related to lack of support for
>> <picture>
> 
> That's right. That is why Mat will be changing the draft spec

That is not fully correct, I think: Mat changed his direction not only 
because of temporary "lack of support" complexity *but also* because he 
saw that their model (double @alt) would *end up* complex, once 
<picture> was supported.

> to use
> <img> with alt for the short text alternative not <picture> and a new
> text alternative method.
> http://lists.w3.org/Archives/Public/public-html/2012Sep/0016.html


It is a move towards allowing alternative text via fallback markup 
content (as opposed to just via attributes), and hence a postive step.

> He will be monitoring the outcome of Issue 30 for how to proceed on a
> long text alternative.

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

Browsers: I believe it would not work in a single one of the browsers
          that you list. E.g. it would not work in iCab. Why not?
          Because you cannot access the context menu for an image
          that is hidden behind another element. There would also
          not be a visual cue, like a mouse pointer change, to 
          signal the presence of longdesc, since these too do not
          react to things hidden behind other elements.
          I am further more not optimistic that these things could
          change, but what do I know.

      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?

I know about *one* responsive image polyfill - the 
'responsive-images-right-now' technique - which places the <img> 
element *above* the <picture>, but makes the <img> transparent, via 
CSS. (Impressing!) [*]  And, of course, if <picture> had followed a 
model like that, then @longdesc would work fine with it. (However, the 
<picture> draft is not based on that polyfill - whether or not that 
matters.)

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

Your, Mat and other’s evaluation of and comments one these problems 
with the @longdesc on <img> as a solution for <picture> would be 
welcome!

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

And this where I feel your "needless complexity" claim is undue: If we 
design <picture>, we do of course try to make it work *now* - 
*everywhere*. And that leads to complexity. It is unfair to use that 
against it unless you also include how complex it is to make @longdesc 
work *everywhere* now, as well. If you think it is *OK* to not make 
@longdesc work in NVDA and VoiceOver, then perhaps it is OK that the 
alternative to @longdesc does not work perfectly as well?

> [1] http://www.d.umn.edu/~lcarlson/research/ld.html

-- 
leif halvard silli

Received on Friday, 7 September 2012 00:26:28 UTC