- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Mon, 24 Sep 2012 10:33:53 +0200
- To: "Geoff Freed" <geoff_freed@wgbh.org>, "James Craig" <jcraig@apple.com>, "Sam Ruby" <rubys@intertwingly.net>
- Cc: public-html-a11y@w3.org
On Sun, 23 Sep 2012 22:44:34 +0200, Sam Ruby <rubys@intertwingly.net>
wrote:
> On 09/23/2012 04:16 PM, Geoff Freed wrote:
>>
>> Just for the record, I think that @longdesc *should* be improved. If
>> the name remains the same, fine. If it changes or is moved to ARIA,
>> fine. I just don't want it to go away before that new Thing is
>> available.
>
> I must say that that's an eminently reasonable position to take.
And is exactly my opinion...
> Geoff: I gather that James hasn't convinced you that iframe is a
> superior solution to address the challenges you face.
I'm not convinced for reasons I explained yesterday.
Which is where the disagreement has arisen. The one thing I have seen that
convinces me that it could solve the problems is the proposal for
aria-describedat.
(I note in passing that there are other techniques that can be used to
present long descriptions which are applicable to a number of use cases.
However, these do not meet the set of real-world requirements I see which
longdesc does).
> Again I ask: is there any chance that we can get a consensus spec out of
> this: one that doesn't attempt to portray publishing software that
> produces markup including longdesc as non-conforming; nor does it
> attempt to portray user agent software that doesn't natively implement
> longdesc as non-conforming?
>
> Geoff: if such an extension specification were written, could you live
> with that for now?
In case we can get consensus on such an approach, I'll draft an extension
spec.
I believe it is a compromise. But it is one I could live with.
cheers
Chaals
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals@yandex-team.ru Find more at http://yandex.com
Received on Monday, 24 September 2012 08:34:28 UTC