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.
>> 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.
>> [*] 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.
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.
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.
>>>> 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>
[1]
<http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/#test1>
[2]
<http://malform.no/testing/a-demo-of/picture-element-accessible-longdesc/#test2>
--
leif halvard silli