Re: Adaptive Image Element Proposal

Mathew Marquis, Wed, 12 Sep 2012 12:01:42 -0400:
> On Sep 11, 2012, at 10:10 AM, Leif Halvard Silli wrote:
>> Laura Carlson, Tue, 11 Sep 2012 06:23:30 -0500:
>  [ … ]
>> 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?
> 
> I feel we could put together a somewhat representative test case for 
> this behavior using the `canvas` or `video` tags with a fallback 
> image, though I’m not sure if it would be a 1-1 comparison. I can put 
> those test cases together, but I may not have time to test much — 
> perhaps that’s something we could open up to the community?

Such demos could help clarifying where <picture> can do the same or 
must do something different.

>> 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.
> 
> I’m not sure what you mean in terms of “overlay”—you mean from a 
> rendering standpoint?

Yes.

> In browsers with native support for `picture`, 
> the fallback image would never be rendered at all.

Is the fallback of <canvas> rendered? It is rendered to some users.

> The behavior of 
> Harry Roberts’ polyfill wouldn’t be indicative of the final native 
> behavior; I believe it uses absolute positioning to do as you 
> describe above.
 
We need something that can help us understand the intende final native 
accessibility behavior *including* how it is going to be achieved from 
a technical point of view.

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

> but one of the key points of difference is this: as new 
> media queries are specced and implemented, we’ll be able to make even 
> greater use of `picture` over time.  [ SNIP ] Unless 
> those were implemented independently in `srcset`, those would be 
> unavailable to us.

This sounds like a good point. It does sound as if <picture> has a 
potential from the media queries angle.

  [ SNIP ] 
> So, that said: I have yet to see a user benefit cited in favor of 
> `srcset`. It fulfills only a faction of `picture`s use cases today, 
> and has incredibly limited potential for the future. It doesn’t stand 
> to benefit users more than `picture` — and fortunately, authors 
> prefer the solution that *does* stand to have greater user benefit. A 
> good situation to be in, I’m sure we can all agree.

It seems to me that, until further, there are user benefits for 
@srcset, namely that it allows images to function the same way they 
function today, both with regard to @alt attribute, @longdesc attribute 
and @usemap.
 
>>> 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.
> 
> All things considered, the deciding factor here seems to be whether 
> AT would be able to “reach into” the `picture` element to determine 
> the attributes and content set within — if that is how things work, 
> the behavior of `picture` with a fallback image will be no different 
> from an independent `img` tag. 

For @longdesc, then on a normal <img> it is available even to non-AT 
like iCab and Opera and Firefox with addons. If the same is not 
possible for <picture>, then some will probably ask for justification 
for that.
 
> We shouldn’t let our decision on the best *native* solution hinge on 
> the behavior of a single JavaScript solution that wasn’t designed to 
> perfectly align with the proposed native behavior.

I think the polyfill solutions shows that it is possible to create 
accessible polyfills that are as accessible as <img> without polyfill - 
simply because the polyfills makes use of the <img> element.  The 
question the accessiblity of the native solution.

[ SNIP ]
-- 
leif halvard silli

Received on Friday, 14 September 2012 12:01:41 UTC