RE: 48-Hour Consensus Call: InstateLongdesc CP Update

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). 


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

Received on Tuesday, 25 September 2012 22:14:05 UTC