- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Thu, 9 Feb 2012 20:29:10 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- 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>, 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>
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? 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. -- Leif H Silli
Received on Thursday, 9 February 2012 19:29:49 UTC