- 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>
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 > http://www.d.umn.edu/~lcarlson/research/scottjehl-picturefill/external/carvingdesc.html > when activated) in: Why is it relevant to test how Scott Jehl's Picture Fill technique works? 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, not? 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 that. > 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 works. [1] http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/#test2 [2] http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/#test1 [3] http://csswizardry.com/2011/07/responsive-images-right-now/ -- leif halvard silli
Received on Tuesday, 11 September 2012 14:10:45 UTC