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

On Thu, Feb 9, 2012 at 11:29 AM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
> Jonas Sicking, Wed, 8 Feb 2012 18:47:56 -0800:
>> 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.
>
> Just to clarify: Are you saying that whenever @aria-describedby points
> to *non-hidden* content, then Firefox presents the fragment[s] that it
> points to with full semantics?

Yes.

> In my previous tests, with VoiceOver, then I could not hear any
> difference that depended on whether the element[s] to which
> @aria-describedby pointed, were visible or not.

Please file a bug and provide a testcase. Feel free to cc me.

https://bugzilla.mozilla.org/

/ Jonas

Received on Friday, 10 February 2012 17:28:20 UTC