RE: Adaptive Image Element Proposal

> From: Leif Halvard Silli [mailto:xn--mlform-iua@målform.no]
[...]
> 
> Because it could impact on ISSUE-30, here are some data on whether
> @longdesc on <img> would be ideal for <picture>. Let's start with an
> example:
> 
> <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. That is: Support
>           would be worse, when used on an <img> inside <picture>
>           compared with outside <picture>.

How do you know this? Did you make a test page and use the specific browsers/devices cited in the research page you reference?

I'm not trying to pick a fight, but if you are going to toss a definitive, broad-sweeping answer to your own question out there while citing someone else's research, I want to see similar rigor in your assertion.


> 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. There would also
>           not be a visual cue, like a mouse pointer change, to
>           signal the presence of longdesc, since these too do not
>           react to things hidden behind other elements.
>           I am further more not optimistic that these things could
>           change, but what do I know.

Ok, did you try iCab? I cannot, I don't have it installed and I'm not about to go through that process if you have already done it and can definitively say that's true.


>       AT: ATs are *probably* more lucky, since they they tend to not
>           rely on contextual menus. Perhaps e.g. Steve understand
>           more on this problem?

Yeah, I would hope AT would be able to access it -- I am not an expert user and cannot say either way.


> I know about *one* responsive image polyfill - the 'responsive-images-right-
> now' technique - which places the <img> element *above* the <picture>,
> but makes the <img> transparent, via CSS. (Impressing!) [*]  And, of course,
> if <picture> had followed a model like that, then @longdesc would work fine
> with it. (However, the <picture> draft is not based on that polyfill - whether
> or not that
> matters.)
> 
> [*] http://csswizardry.com/2011/07/responsive-images-right-now/

> 
> This is as complex as anything else. But of course, on the good say: If one
> manages to use that polyfil, then the <picture> should work as well as <img>
> does, both with regard to @alt and @longdesc.

I don't know this applies here. As far as I understand it, we want to create a solution that doesn't need a polyfill. Discussing how a polyfill does it is interesting in that it shows us how a workaround functions today, but it doesn't do much except to let us know there is still work to be done on this.


> Your, Mat and other’s evaluation of and comments one these problems with
> the @longdesc on <img> as a solution for <picture> would be welcome!

Is there an existing test page somewhere? Not asking as a passive-aggressive way to get someone to make one, I'm just wondering if there is something already out there.


> >> Even @longdesc is very complex if you want to implement support for
> >> it in AT which do not support it already.
> >
> > Recent research finds that modern screen readers have good support for
> > the longdesc attribute [1].
> 
> Yes, but the fact that NVDA and VoiceOver doesn't support it could be a
> concern, to some. For these users, the long description would be hidden.
> (But, once Firefox finalizes its VoiceOver support, then perhaps we will see it
> in VoiceOver? So far that is vapor ware, though.)

Yes, it could be a concern to those users. But those users are already dealing with lack of @longdesc support. There is no reduced functionality here as a result of this (for the NVDA/VO users)


> And this where I feel your "needless complexity" claim is undue: If we design
> <picture>, we do of course try to make it work *now* - *everywhere*. And
> that leads to complexity. It is unfair to use that against it unless you also
> include how complex it is to make @longdesc work *everywhere* now, as
> well. If you think it is *OK* to not make @longdesc work in NVDA and
> VoiceOver, then perhaps it is OK that the alternative to @longdesc does not
> work perfectly as well?

I am of the opinion that @longdesc exists and has support, even if the support isn't ideal, and so is the natural long text alternative content holder. There is already more support for @longdesc today than there would be for a <desc> element (or the absence of an element), particularly because the content of a <desc> element (or not-element) will be forced on users on older browsers who don't want or need it. Expecting authors to style that away without impacting accessibility seems like a far reach here.

Received on Friday, 7 September 2012 15:25:26 UTC