Re: Drop longdesc, get aria-describedat?

Hi, Leif:

Leif Halvard Silli writes:
> Janina, Richard - and the ARIA community. The F2F Minutes Extract on 
> Action-970 says: [1]
> 
> > rich: [ snip ] when we do describedat, will ask browsers for
> >       a vehicle to render that location
> 
> Question: Is there a chance that "we could do" @aria-describedat *now*? 
> I am convinced that the chances for a amicable solution would increase 
> greatly if one could move from talk to action with regard to 
> @aria-describedat.
> 

You're asking the core question, imho. I wish we could simply say "yes"
and be done with it, but there's a problem that prevents us from doing
that--a big problem. ARIA-Describedat does not yet exist. Meanwhile, a
long text description mechanism continues missing from the HTML 5 spec.
That's unacceptable.

Unfortunately, ARIA-DescribedAt doesn't exist anywhere except on our "To
Do" list. It's on our list for the NEXT iteration of the ARIA
specification because it's too late to put it into the current version
of ARIA. We're simply too far down the road toward W3C guideline status
to pull back for this one feature. We're most of the way through
Candidate Recommendation (CR) status. To pull back now and add
Describedat would set us back many months--possibly a year. That's also
unacceptable.

That leaves only longdesc on the table. It exists today, it's
implemented and used today. It should be in the spec today.

The HTML Chairs simply got it wrong in their Issue-30 decision back in
August 2010 when they claimed longdesc wasn't needed because:

"alternatives exists (explicit links, aria-describedby, figure captions) ..."
http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html

As we've since discovered in much discussion, Describedby wasn't an
workable option then, and it isn't one now. Neither are Fig-Caption or
direct links workable options today--or then.

> > agreement in room: longdesc and describedat are preferable to this
> > because they're so very much simpler
> 
> There are potential problems related to having both @longdesc and 
> @aria-describedat: @longdesc as a HTML5 native feature, would be the 
> HTML WG's domain. It is not clear to me, yet, what rules you plan with 
> regard to @aria-describedat's permission point to for example sections 
> that are hidden via aria-hidden=true. But what is certain is that 
> @longdesc would be subject the rules that the HTMLwg decides also in 
> this detail.
> 
> Whereas the rules for aria-describedat, would be entirely in the hands 
> of PF/the ARIA community. When we consider how difficult it seems to be 
> to agree about how to @hidden relates to ARIA, it seems to me to it 
> *could* be an advantage if we only had @aria-describedat instead of two 
> attributes with potentially different rules.
> 
> We could also view it tactically: The negativity towards @longdesc 
> could - if the two attributes get linked in people' mind - spill over 
> to @aria-describedat. Also, as long as neither @longdesc nor 
> @aria-describedat are legal, then neither author or vendors are picking 
> any of them up.
> 

They can't pick up Describedat because, it doesn't exist, not in our
spec, not in browsers, not anywhere except in our intentions. Someday it
will exist. Until then the longdesc attribute meets the current need and
should simply be retained. That it isn't is a slap in the face to
accessibility, imho.

Janina

> [1] http://lists.w3.org/Archives/Public/wai-xtech/2012Mar/0004
> -- 
> Leif Halvard Silli

-- 

Janina Sajka,	Phone:	+1.443.300.2200
		sip:janina@asterisk.rednote.net

Chair, Open Accessibility	janina@a11y.org	
Linux Foundation		http://a11y.org

Chair, Protocols & Formats
Web Accessibility Initiative	http://www.w3.org/wai/pf
World Wide Web Consortium (W3C)

Received on Wednesday, 7 March 2012 16:48:26 UTC