- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 10 Feb 2012 09:27:22 -0800
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Cc: Charles Pritchard <chuck@jumis.com>, 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>, 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 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