Re: Adaptive Image Element Proposal

Laura Carlson, Fri, 7 Sep 2012 17:54:27 -0500:

>> <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...
>> 
>> 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.
> 
> This is incorrect Leif. It seems to work in all of them that I tested.
> 
> Here is a test page:
> http://www.d.umn.edu/~lcarlson/research/constriants/picture-test.html

When your message arrived, it was 3,5 hours since my reply to Adrian, 
where I included links to the <picture> test upon which I based the 
above claims. [*] But there is nothing in your message that signals 
that you or Geez have seen or evaluated that test page. So I am gonna 
assume that you deemed me incorrect without having checked my test page.

|*] http://lists.w3.org/Archives/Public/public-html/2012Sep/0064

I checked your test page:

(1) There is no responsive image  - or polyfill features that are
    typical for such images -  in that test - it is just an
    <img> with a picture wrapper around. The picture wrapper
    does not contain any image (via CSS) like the responsive
    image polyfills always do. Obviously, in a picture polyfill
    the picture image would (normally) cover the image of the img
    element, which in turns makes the img inaccessible for 
    contextual menu access.

(2) To insinuate that I said that an unstyled <picture> element
    would create anymore problems than an unstyled <div> or <span>
    really isn't very helpful.

From my perspective, in its current form, your test page does not 
enlighten the problem with contextual access to longdesc when the <img> 
is behind another image.  Therefore, we can *not* have a debate of that 
problem based on that page as it stands. The only value I see it in it 
is that it demonstrates that support for @longdesc on the <img> element 
is alive and kicking.

I really have a hard time understanding why it is so hard to admit 
that, given a polyfill technique for a responsive image that bases 
itself on <video> elemen model, then special care needs to be taken if 
one wants the child element's longdesc attribute to be accessible to 
users of browsers with contextual menu access to the longdesc link. 
Yeah, the only way to completely avoid that problem would be by 
canceling the <video> element model and instead go for a model were we 
extends the very <img> element with more attributes and more CSS - a la 
what Aaron demoed:

 http://blog.easy-designs.net/archives/2012/04/16/iir-redux/

But as for responsive image techniques that are more a la the <video> 
element, then here are some article - it is these kinds of polyfill 
techniques that needs to be checked with regard to longdesc 
accessibility

 http://csswizardry.com/2011/07/responsive-images-right-now/
 https://github.com/scottjehl/picturefill 
 http://nicolasgallagher.com/responsive-images-using-css3/
 http://css-tricks.com/which-responsive-images-solution-should-you-use/

And my test page I notified you about, do try to check the longdesc 
accessibility for that kind of polyfill:

http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/
-- 
leif halvard silli

Received on Saturday, 8 September 2012 00:24:49 UTC