- From: <bugzilla@jessica.w3.org>
- Date: Thu, 26 Sep 2013 22:23:38 +0000
- To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23370 --- Comment #2 from James Craig <jcraig@apple.com> --- (In reply to Leif Halvard Silli from comment #1) > Some comments just to clarify that we are on the same page: > > The consequence of @hidden being in the strong native semantics table is > that it would be forbidden to set its aria-hidden state to _false_: > > <foo hidden="" aria-hidden="false"> This is one of the problems with this row in the table, but not my main point. > But the this would still be allowed - but redundant: > > <foo hidden="" aria-hidden="true"> > > If @hidden was placed in the ”weak” table, it would not be forbidden to > “override” it with a aria-hidden="false". Moving this row to the "weak" table would work for me. > But your focus i aria-hidden="true" - not aria-hidden="false". Not necessarily. That's tangential to my point, but WebKit exposes the following to the AX API. Other UAs don't, but they should. <div hidden aria-hidden="false">Only AT gets this text</div> > And in that > regard, then is a piece of cake to make elements with @hidden *visible*: > > [hidden]{display:block}) > > As such, it would per my understanding be possible to solve your usecase > (visible elements that should be hidden to AT users) the following way: > > <div style="display:block" hidden=""> > Visual clutter that should be hidden from AT > </div> That does work, but it's hacky since it forces an overwrite of the default style for @hidden. > But of course, it could be simpler to skip both the @style and the @hidden > and just use aria-hidden. And in my view, @hidden in the strong table does > not prevet aria-hidden="true" from being applied to elements without @hidden. > > Thus I don't see the problem that you see - one of us is probably reading > something wrong ... :-) You're suggesting this, which I agree is the right approach, but the spec is written to disallow this use due to the strong native semantics of @hidden. <div aria-hidden="true"> Visual clutter that should be hidden from AT </div> The problem is that @hidden is a boolean attribute, so its absence indicates that the element is *not* hidden, and therefore aria-hidden="true" would be in conflict with the host language attribute. ARIA defines conflict resolution here: http://www.w3.org/WAI/PF/aria/complete#host_general_conflict "When a host language declares a WAI-ARIA attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic." Therefore, because this "strong native semantics" table is conflating @hidden and @aria-hidden, and the HTML spec allows @hidden on all elements, it is explicitly declaring that @aria-hidden has no effect in HTML5, which is obviously problematic, because the user agents MUST ignore aria-hidden and use the host language attribute on the following element (missing @hidden implicitly means "not hidden", even to API): <div aria-hidden="true"> Visual clutter that should be hidden from AT </div> I propose the change be to remove that line from the "strong" table (and possibly add it to the "weak" table) because the @hidden and @aria-hidden actually mean different things: @hidden indicates the element is not rendered in any modality unless: - visually overridden with @style. - semantically overridden with @aria-hidden for accessibility APIs. @aria-hidden is an explicit override for any display property that only affects accessibility APIs, and always trumps other display settings or attributes for the output to said APIs. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 26 September 2013 22:23:39 UTC