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

On Fri, Apr 22, 2011 at 12:13 PM, Steve Faulkner
<> 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:09:05 UTC