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

Re: 48-Hour Consensus Call: InstateLongdesc CP Update

From: Charles McCathie Nevile <chaals@yandex-team.ru>
Date: Wed, 26 Sep 2012 10:06:10 +0100
To: "Sam Ruby" <rubys@intertwingly.net>, "Cynthia Shelly" <cyns@microsoft.com>
Cc: "Geoff Freed" <geoff_freed@wgbh.org>, "James Craig" <jcraig@apple.com>, "public-html-a11y@w3.org" <public-html-a11y@w3.org>
Message-ID: <op.wk8a8kmiy3oazb@chaals.local>
On Tue, 25 Sep 2012 23:12:53 +0100, Cynthia Shelly <cyns@microsoft.com>  

> How about a title of "HTML 5 Long Descriptions" or something similar,  
> that does not use "image"?  There has been some talk of extending this  
> functionality to other elements (for example video).

Sure and I think that is probably a good idea, but my initial intention is  
to do the very tightly scoped "what HTML 4 had for images" - and then get  
out of the way and let the talkers work on further extension. Partly  
because I believe the nothing-new version can be finished in a matter of  
months (the biggest delay is if we wait 150 days from FPWD for patent  
exclusions - but in that time we could probably be ready to publish a  
Recommendation, if we agree on the spec).


> -----Original Message-----
> From: Charles McCathie Nevile [mailto:chaals@yandex-team.ru]
> Sent: Monday, September 24, 2012 6:29 AM
> To: Sam Ruby
> Cc: Geoff Freed; James Craig; public-html-a11y@w3.org
> Subject: Re: 48-Hour Consensus Call: InstateLongdesc CP Update
> 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

Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com
Received on Wednesday, 26 September 2012 06:06:44 UTC

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