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/picturefillhttp://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