RE: Adaptive Image Element Proposal

Been taking advantage of some of my weekend, sorry for the delay.

> From: Leif Halvard Silli [xn--mlform-iua@xn--mlform-iua.no]
> 
> Adrian Roselli, Fri, 7 Sep 2012 15:24:53 +0000:
> >> From: Leif Halvard Silli:
> 
> >> 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?
> 
>  # First, I made the assumption that it would not work
>    in contextual menu based solutions.
>  # Then I made a picture element for testing. [1]
>  # Then I tested that test element in iCab.
>    (Later, after your question, I also tested in
>     in Opera.)
> 
> As for Laura's test page, then I have contributed to to. I'm not
> opposed to longdesc as such - and if @longdesc is permitted in HTML5,
> then it would also be permitted inside picture. So we should consider
> how it works, regardless.

Agreed, knowing how it would function in today's browsers is good.


> >>       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.
> 
> Well, you should not take my sound reasoning for it any more than for
> contextual menu based solutions? I have not documented what I said ...
> But I believe it is entirely possible to clutter it up so it don't
> work. It only requires that the <img> is, in some way or another,
> hidden from AT. Some authors will probably err.

This is the part where I have to defer. I don't know if most AT users would access @longdesc from a right-click menu nor if the absence of @longdesc from a right-click menu means that it isn't exposed in any AT layers at all.


> >> [*] 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.
> 
> What doesn't apply? Polyfill? Well @longdesc without polyfill does not
> work for <picture> in browsers which support longdesc via a contextual
> menu. End of _that_ story, I think.

Having run through your test pages (on my netbook using Firefox and Opera, but that's it since my test machines aren't here), I can see the missing @longdesc option in the context menu.

I am resistant to proposing a polyfill when there is a pure-HTML solution/option available. I don't know that there is yet -- again, I am not an expert AT user so I am trying to avoid broad statements with which I have little practical experience.


> Mat's spec is based on a polyfill - which thus serves as a prototype.
> And, one it is important to think about whether the solution in the
> polyfill works compatibly - or different from - the end goal solution.
> Also, I try to be modest with regard to what to expect from vendors ...
> 
> But I replicated - and tested - the 'responsive–image-right-now'
> technique in my test page.[2] Thus you can verify that it works - for
> example by testing in Opera. From that point of view, it is a success.
> It really does work. But it does require a polyfill - just as the
> not-longdesc based solution do.

I do see that the menu (re)appears in your second example.


> AND BY THE WAY: It would/could be possible to combine the solutions.
> E.g. one could use the @longdesc as polyfill, in conjunction with a
> fallback based solution. I think that authors should be permitted to
> provide the fallback via markup as long if they want and know how to do
> it.

I am not against combining solutions, but again I am a little out of my arena and don't feel I can give an educated opinion on that (yet).


> >>>> 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)
> 
> Yeah, it would be a status quo solution. (Though, in honesty, if one
> wants, then one could help NVDA+Firefox to handle @longdesc with some
> aria-polyfill.)
> 
> > 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.
> 
> The alternative to @longdesc does not need to be Laura's <desc>. It
> could be a link:
> 
>   <picture>
>     <img src=file alt="Photo." >
>     <span>Short description.</span>
>     <a href=longdesc>Link.</a>
>  </picture>

I am back to my prior argument that text inside a <picture>, outside of an attribute, delivers content to users that don't need/want it. Whether it's a link, a <desc>, or a <span>, it's still extra content. Now, the link you suggest at least addresses the issue with pushing too much content and also with the issue of being able to re-use content. I do like that if we are in a position where an attribute just can't work.

Before I believe we are at that point, I'd like to hear more from others who use AT and/or work with those who do. While I work with many who do, I am only one perspective on this.

Received on Sunday, 9 September 2012 13:25:20 UTC