InstateLongdesc CP Update from Charles McCathie Nevile on 2012-09-24 (public-html-a11y@w3.org from September 2012) (original) (raw)

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