W3C home > Mailing lists > Public > public-html@w3.org > February 2012

Re: Using @aria-describedby for long described image links [Was: Using an image map for long described image links [Was: Revert Request]]

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 8 Feb 2012 18:47:56 -0800
Message-ID: <CA+c2ei_rAW4zJB_1brySpEbD5Go9H9MthKTX-a7dSmqpfxiy9A@mail.gmail.com>
To: Charles Pritchard <chuck@jumis.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Steve Faulkner <faulkner.steve@gmail.com>, Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, John Foliot <john@foliot.ca>, Matthew Turvey <mcturvey@gmail.com>, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Laura Carlson <laura.lee.carlson@gmail.com>, Sam Ruby <rubys@intertwingly.net>, Paul Cotton <Paul.Cotton@microsoft.com>, HTML WG <public-html@w3.org>
On Tue, Feb 7, 2012 at 12:40 PM, Charles Pritchard <chuck@jumis.com> wrote:
>> I don't think Apple has a strong stance either way on using
>> @aria-describedby to point to @hidden elements, but I believe we could
>> reasonably expose full semantics of hidden content pointed to by
>> aria-describedby, this is more or less the same as the work we'd have to do
>> to expose <canvas> children as an accessible tree.
>
>
> <canvas><button /></canvas> is not the same as <canvas><button hidden
> /></canvas>.
>
> Elements within the canvas subtree are not hidden, though. It's apples to
> oranges, though both fruits.
> "The hidden attribute is a boolean attribute. When specified on an element,
> it indicates that the element is not yet, or is no longer, relevant. The
> hidden attribute must not be used to hide content that could legitimately be
> shown in another presentation."
> http://www.w3.org/TR/html5/editing.html#the-hidden-attribute

The semantic meaning of the contents of a canvas is obviously
different from the semantic meaning of the contents of a hidden
element.

However implementation-wise, the reason that they are special when
exposed to AT is exactly the same.

In firefox, the reason that @hidden elements are "stringified" when
exposed through aria-describedby is because they don't have CSS boxes.
This is also why we have problems currently when exposing the contents
of a <canvas>. In both cases the accessibility code "fails" because it
tries to use the CSS boxes which aren't there. Hence the fallback to
stringify.

It sounds like Apple has solved this in their AT code for <canvas>
such that it can work despite a lack of CSS boxes. I believe Maciej is
saying they can probably use the same solution to expose the full
semantics of @hidden elements pointed to be aria-describedby.

Exposing the rich semantics of contents inside a <canvas> in Firefox
will take a lot more than changing what object <canvas> inherits from.
Whatever solution we come up with for that can hopefully be reused to
expose the rich contents of @hidden elements exposed through
aria-describedby.

We now have two implementations which say that exposing the rich
contents of @hidden elements pointed to using aria-describedby is
implementable. And is implementable without changes from AT vendors.

If people still want to mark such pages invalid, or even specify that
browsers should ignore such descriptions, please do so because you
think that it's good for accessibility. Not because you think it can't
or won't be implemented.

/ Jonas
Received on Thursday, 9 February 2012 02:48:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:43 GMT