Re: describedBy and longdesc

On Sun, 27 Mar 2011 07:14:53 +0200, John Foliot <jfoliot@stanford.edu>  
wrote:
> Leif Halvard Silli wrote:
>> Charles McCathieNevile, Sat, 26 Mar 2011 11:23:07 -0400:
>> > On Fri, 25 Mar 2011 22:34:27 -0400, Jonas Sicking wrote:
>> >> On Fri, Mar 25, 2011 at 6:57 PM, Laura Carlson :
>>
>> > aria-describedBy, if fixed, and generally applicable, would be better
>> > than longdesc. I hope that in some time this will happen, and
>> > longdesc will become obsolete.

> SETTING THE STAGE:
>
>  "ARIA is intended to only affect accessibility API mappings (and
> thus ATs). Features such as alt="", however, are relevant far beyond AT
> users, for example to text browsers. It would be wrong, therefore, to  
> make solutions that exclusively affect accessibility APIs be a suitable
> alternative for solutions that are necessary for UAs that do not use
> accessibility APIs."

Agree, and this is something that is wrong with ARIA as currently  
specified.

>> I for my part agree with Laura that the @aria-describedAT proposal is
>> an acknowledgement of @longdesc's unique features. I think we need
>> accurately specified A11Y features. Allowing too much freedom soon ends
>> up like a - ah - certain lottery. Thus it doesn't seem like the right
>> approach is to overload @aria-describedby - or any other ARIA attribute
>> - with multiple semantics.
>
> +1

I think that longdesc is, but only for images, what aria-describedBy tries  
to be more generally. There is a benefit in the specification of  
aria-describedBy that is explicitly enables identification of the  
description, not just where it begins (which is all longdesc does by  
specification).

> Yet one of the complaints we've repeatedly heard is that the text
> contained in the page pointed to by @longdesc might be useful for sighted
> users as well...

No reason longdesc can't do that already

> ...because there is no visual indication that @longdesc content exists...

That's just because implementations are bad, and can be fixed in any  
modern browser in about 30 minutes of work.

> This ...line of discussion is ... suggesting to re-open a Candidate
> Recommendation (ARIA 1.0) to either re-work an existing attribute, or
> introduce a new one. It is breaking backward compatibility with an
> existing 12 year old specification. It dogmatically rejects an existing
> attribute in favor or creating a new attribute that does exactly what the
> old attribute did.

Given that we have the old attribute, and understand some of the things  
wrong (and right) with it, I believe we are throwing it away too early. If  
we fix aria-describedBy, then we simply have redundant syntax (which is a  
trivial issue), and if we discover that one or the other is broken in some  
unanticipated way then we can expect them to wither and die when they are  
really dropped - accessibility attributes seem unlikely to live on beyond  
their usefulness.

In the long run aria-describedBy matches a whole set of things I expect to  
be used, and since its functionality in principle overlaps that of  
longdesc I expect it to become capable of doing that in practice. At which  
point longdesc becomes obsolete - replaced by another attribute with a  
more popular name, that does the same things. That's fine. When the new  
attribute can do the important things that the old one did. Which is not  
yet.

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com

Received on Tuesday, 29 March 2011 13:39:27 UTC