W3C home > Mailing lists > Public > public-respimg@w3.org > September 2012

Re: Adaptive Image Element Proposal

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Tue, 11 Sep 2012 16:10:01 +0200
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: Adrian Roselli <Roselli@algonquinstudios.com>, Mathew Marquis <mat@matmarquis.com>, Peter Winnberg <peter.winnberg@gmail.com>, Steve Faulkner <faulkner.steve@gmail.com>, HTML WG <public-html@w3.org>, "public-respimg@w3.org" <public-respimg@w3.org>
Message-ID: <20120911161001749611.f5d35d73@xn--mlform-iua.no>
Laura Carlson, Tue, 11 Sep 2012 06:23:30 -0500:

> I put together a test of longdesc for responsive images with a
> variation of Scott Jehl's Picture Fill:
> http://www.d.umn.edu/~lcarlson/research/scottjehl-picturefill/index.html

> Test Results:
> Reveals and works correctly at all sizes from small to extra large
> (e.g., opens description page

> when activated) in:

Why is it relevant to test how Scott Jehl's Picture Fill technique 

The reason why your test of Picture Fill works is the same reason why 
my varian Responsive-Images–Right-Now test works: [1] The topmost image 
resource that users get, is an <img> element.

My question is: Can we expect the same to happen for <picture>, when 
*implemented*? Is it not more likely that these longdesc links will 
stop to function - at least with regard to contextual menu access - 
once <picture> support kicks in? That's a question we need to clarify, 

After all, <picture> would work even without <img> (according to the 
plans I've seen so far), so why would users be given access to the 
child <img> element? Yes, I can imagine that it would work not bad (but 
perhaps not perfect) for screen reader users. But contextual menu users 
would not get access, I think: THey - and others who need to "touch" 
the <img> in order to get its features - would only get the same 
experience as in my test 1.[2]

By the way: We have (please test to verify!) the same situation today 
for <canvas>: If someone places a <img> with a longdesc inside a 
<canvas>, then contextual menu access users will not get access to the 
longdesc unless the <canvas> fails to load so that users get the 
fallback instead. HOWEVER, screenreader users and other AT users might 
still get access. And perhaps that is good enough?  May be not all 
users need access to @longdesc - perhaps that is to aim too high?

We don't know ho <picture> will end up functioning, but we should 
assume that its (rendered) graphic resource will overlay the image of 
the child <img> element. If we should expect something else, then 
please - Mat or whoever - gives us reason to believe so. Until then: 
Provide @longdesc and @alt really aer crucial, the I come back to the 
conclusion that it is better to drop <picture> and instead go for 
extending <img> with @srcset etc. Because, in that case, there would be 
no doubt thagt the <img> element lands on top.

In the debates about <picture> on WHATWG, it seems like Mat's reason 
for going for <picture> rather than for @srcset on <img>, has to do 
with authoring convenience. Then remember that, provided @longdesc and 
@alt is a must, the much debated HTML5 design principles put users 
needs above author needs. 

> Leif, I also checked your test page:
> http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/

> The images on this page do not seem to be responsive images but static
> images.

Like I say in test 2,[1] that specific test is a inspired by Harry 
Roberts’ “responsive images right now”-technique. [3] However, there is 
no "break point" in that test - so there is only one image size ... It 
is not necessary, for the subject at hand, that it is more real than 

> Anyway my results of that testing:
> iCab Native
> Control: Contextual menu works
> Test 1: Contextual menu doesn't work
> Test 2: Contextual menu works
> Opera Native
> Control: Contextual menu works
> Test 1: Contextual menu doesn't work
> Test 2: Contextual menu works
> Firefox/w Patrick's longdesc extension
> Control: Contextual menu works
> Test 1: Contextual menu doesn't work
> Test 2: Contextual menu works

Thanks for confirming my tests results w.r.t. iCab and Opear. The 
Firefox addon result was new - but unexpected - thanks for that. As I 
mentioned somewhere, I have also tested that page with JAWS - where it 



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

leif halvard silli
Received on Tuesday, 11 September 2012 14:10:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 September 2012 14:10:44 GMT