- 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