W3C home > Mailing lists > Public > wai-xtech@w3.org > April 2011

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

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Fri, 22 Apr 2011 22:25:37 +0100
Message-Id: <8471B8AB-22B6-4F72-B98F-56B072B78F17@gmail.com>
Cc: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Michael Cooper <cooper@w3.org>, Joseph Scheuhammer <clown@alum.mit.edu>, W3C WAI-XTECH <wai-xtech@w3.org>, HTMLwg <public-html@w3.org>, Richard Schwerdtfeger <schwer@us.ibm.com>, David Bolter <dbolter@mozilla.com>
To: Jonas Sicking <jonas@sicking.cc>
Hi Jonas 

> I wrote a patch in about 30 minutes to do so. 

Interesting, so how is this behaviour exposed to users?

Feedback received from the NVDA developers was that they want UI in the browser.

How does it affect current expected behaviour for describedby?

Sent from my iPhone

On 22 Apr 2011, at 22:08, Jonas Sicking <jonas@sicking.cc> wrote:

> On Fri, Apr 22, 2011 at 12:13 PM, Steve Faulkner
> <faulkner.steve@gmail.com> wrote:
>> hi jonas,
>> adding rich and d bolter as they may have some useful input.
>> I suppose it is not so much that people want to restrict it, but how
>> all browsers (as in firefox etc) have implemented describedby.
>> i.e describedby doesn't work the way it is wirtten in the author
>> guide. the way it is implemented is that the text content of any
>> elements referenced are used as the value for the acc description
>> property in accessibility APIs this is a property that can only take
>> plain text (as far as i know) and the content of which can be accssed
>> by AT via the API is just that plain text.
>> the emerging consensus on providing an aria feature like longdesc (for
>> example) is that it will need to be a new feature, not a modified
>> describedby.
> Adding new features to work around shortcomings in implementations of
> existing features is very counterproductive. It means that developers
> have even less time to fix bugs in existing features, and that authors
> have even more features that they have to learn and understand the
> shortcomings of.
> The accessibility spec community is certainly not the only ones making
> this argument. I keep hearing arguments like "feature X has by Y in
> implementation Z, so lets add this other feature to allow web authors
> to work around it" on both the whatwg list and the webapps list. As
> spec authors we need to be able to push back and simply say that
> implementations needs to fix their bugs. Otherwise we're just building
> a giant tangled mess of half-assed features, rather than a coherent
> working vision of a good web platform.
> For example, it would be trivial to make it such that aria-describedby
> pointing to a link acts *exactly* like longdesc for AT users. In fact,
> I wrote a patch in about 30 minutes to do so. The hardest part is
> getting spec authors to agree on what the desired behavior is.
> / Jonas
Received on Friday, 22 April 2011 21:31:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:44 UTC