[Bug 19277] Relationship and precedence of hidden="" and display:none should be clarified/defined

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277

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

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

--- Comment #11 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> 2012-10-06 02:11:07 UTC ---
(In reply to comment #10)
> (In reply to comment #8)
> >
> > Boris, what would you think about shifting the rule to be "display: none
> > !important;"?  Whenever I've used hidden, I've put that rule in my stylesheet,
> > because otherwise I have to code defensively to avoid "un-hiding" things
> > accidentally.
> 
> But isn't this what the Issue 204 decision wants to do? To "un-hide" the
> semantic structure under certain conditions (when referenced by an ARIA
> attribute) so that the structure and content remains intact and "rendered" by a
> speech synthesizer?

What Tab suggested only relates to whether an author would be able to do

   foo[hidden]{display:block} /*Current*/

or if the author would have to do

   foo[hidden]{display:block!important} /*The result of Tab's proposal*/

> Right now, {display:none;} and {display: none !important;} are respected by
> screen readers (as it maps as such to the AAPI). This also brings back the
> question of what/how ARIA aware screen magnifiers are supposed to process this
> content?

A screen magnifier that insists on making the ARIA semantics available to its
user, would probably have to use foo[hidden]{display:block!important}. And this
would work fine in the typical cases.

But note that ARIA allows you to point to for example <script> or <meta>, which
could be situated inside the <head>. I think it is unlikely that screen
magnifiers would be able to make such elements visible. But ARIA still allows
it to be done.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 6 October 2012 02:11:11 UTC