- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Mon, 24 Sep 2012 15:28:48 +0200
- To: "Sam Ruby" <rubys@intertwingly.net>
- Cc: "Geoff Freed" <geoff_freed@wgbh.org>, "James Craig" <jcraig@apple.com>, public-html-a11y@w3.org
- Message-ID: <op.wk46ea0by3oazb@chaals.local>
On Mon, 24 Sep 2012 12:32:26 +0200, Sam Ruby <rubys@intertwingly.net> wrote: > On 09/24/2012 04:33 AM, Charles McCathie Nevile wrote: >> 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. > > Can you explain why aria-describedat might be, in your opinion, an > adequate replacement? Because it does the same things (i.e. meets the requirements I see). It changes the name, > Is there any reason that such an specification could not be pursued in > parallel and meet CR exit criteria by 2014Q2? Well, it needs to be implemented. Like longdesc, that ain't hard. I believe a longdesc spec would meet CR exit criteria today, even while stating that any user agent that didn't directly expose the content to the user is not conformant. > Could it, like we are proposing here, be pursued as a separate > specification[1] and therefore not impact ARIA 1.1 or ARIA 2.0, but just > like we are proposing for HTML be integrated into ARIA once it reaches > maturity and consensus? That depends on how PF manages the ARIA specs, but sure, it is feasible in principle. > Care to comment on the position that David Bolter expressed[2], but I > have heard from others, namely that "part of the beauty of ARIA is that > it is purely annotative semantics that can be added to describe existing > UI without interfering with that UI"? Sure. I think this is one of the major mistakes of ARIA, and I strongly recommend implementors ignore that particular aspect. It provides for a disjointed implementation where user agents who *use* the annotations as designed might essentially turn a page into something completely different from the one rendered by user agents that don't let the ARIA interfere with their UI. The current draft has an each-way bet, saying user agents *may* implement ARIA other than through accessibility APIs. [...] >>> 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. > > Excellent! I have yet to add the use cases and requirements in, but here's a morning's work... >> I believe it is a compromise. But it is one I could live with. cheers -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex chaals@yandex-team.ru Find more at http://yandex.com
Attachments
- text/html attachment: longdesc.html
Received on Monday, 24 September 2012 13:29:29 UTC