W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2013

[Bug 23370] Strong Native Semantics table appears to imply @hidden trumps @aria-hidden

From: <bugzilla@jessica.w3.org>
Date: Thu, 26 Sep 2013 22:23:38 +0000
To: public-html-a11y@w3.org
Message-ID: <bug-23370-3290-f0pc6uoMBC@http.www.w3.org/Bugs/Public/>

--- 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

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:

"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

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:35 UTC