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

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