W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

Re: 48-Hour Consensus Call: InstateLongdesc CP Update

From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 24 Sep 2012 06:32:26 -0400
Message-ID: <506036BA.9050204@intertwingly.net>
To: Charles McCathie Nevile <chaals@yandex-team.ru>
CC: Geoff Freed <geoff_freed@wgbh.org>, James Craig <jcraig@apple.com>, public-html-a11y@w3.org
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?

Is there any reason that such an specification could not be pursued in 
parallel and meet CR exit criteria by 2014Q2?  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?

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"?

> (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

- Sam Ruby

[1] http://dvcs.w3.org/hg/aria-unofficial/raw-file/tip/describedat.html

[2] http://lists.w3.org/Archives/Public/public-html-a11y/2012Mar/0405.html
Received on Monday, 24 September 2012 10:32:55 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:31 UTC