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 21:30:21 +0000
To: public-html-a11y@w3.org
Message-ID: <bug-23370-3290-WiM7OXXnKc@http.www.w3.org/Bugs/Public/>

Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
                 CC|                            |xn--mlform-iua@xn--mlform-i
                   |                            |ua.no

--- Comment #1 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> ---
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">

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

But your focus i aria-hidden="true" - not aria-hidden="false". And in that
regard, then is a piece of cake to make elements with @hidden *visible*:


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

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 are receiving this mail because:
You are on the CC list for the bug.
Received on Thursday, 26 September 2013 21:30:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:56:29 UTC