Re: False aria-describedby expectations in ARIA Authoring Practices (longdesc)

Jonas Sicking, Tue, 26 Apr 2011 13:48:20 -0700:
> On Tue, Apr 26, 2011 at 1:41 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Tue, Apr 26, 2011 at 6:48 AM, Richard Schwerdtfeger <schwer@us.ibm.com>
>> wrote:
>>> 
>>> Hi Jonas,
>>> 
>>> ARIA is going through Candidate Recommendation so changing the browser
>>> implementation this late in the game is problematic. I read through 
>>> the code
>>> and I don't see what the patch does for accessibility. It appears 
>>> to simply
>>> be iterating through valid ids that match the describedby reference. What
>>> are you actually doing with this patch as it is not clear?
>> 
>> Huh? I don't understand why the spec status affects the ability to fix bugs
>> in the various implementations? Going to rec freezes the spec, not the
>> implementations.
> 
> Sorry, forgot to answer the questions regarding what the patch does.
> 
> We already have code to expose longdesc to AT software. What the patch
> does is that it detects that if an image doesn't have a longdesc
> attribute, but does have a aria-describedby which points to a <a> or
> <area> element with a href attribute, it exposes the link in that
> <a>/<area> as being the location of the long description of the image.

Can this be tested in a nightly build or something?

If I get what you said right, then such a link is presented to - for 
instance - Jaws as if it was a @longdesc, right?
-- 
Leif Halvard Silli