W3C home > Mailing lists > Public > public-html-a11y@w3.org > October 2012

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 08 Oct 2012 06:57:23 +0000
Message-Id: <E1TL7HH-0007OK-KU@jessica.w3.org>
To: public-html-a11y@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277

Henri Sivonen <hsivonen@iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsivonen@iki.fi

--- Comment #14 from Henri Sivonen <hsivonen@iki.fi> 2012-10-08 06:57:23 UTC ---
(In reply to comment #7)
> With the decision on Issue 204 however, the WG has reversed even that emergent
> precedent, as now @hidden will NOT map to the same state as aria-hidden="true"
> with regard to the Accessibility APIs.

Do you mean in general or when building the description for aria-describedby?

Note that @hidden being implemented simply via the UA style sheet for
CSS-supporting UAs and the style being display:none; (or display:none
!important;) does not mean the data behind @hidden could not be used in a
context other than the CSS viewport & a11y API view corresponding to what’s in
the CSS viewport. That is, it could still be defined that descriptions rendered
outside the CSS viewport would not be hidden by display:none;.

Precedent:
EPUB3 Navigation Documents use @hidden to hide navigation data when the
Navigation Document is rendered as book content in a CSS viewport but still
show the data when the navigation data is rendered in the Reading System UI
outside the “principal rendering”:
http://idpf.org/epub/30/spec/epub30-contentdocs.html#sec-xhtml-nav-def-hidden

(For the aria-describedby case, consider the hypothetical Voice Over view of
the description NOT a “principal rendering” per the EPUB terminology.)

For browser context precedent of having a case where AT exposure applies
without CSS boxes:
The tree rooted at <canvas> is defined to be exposed to AT even though it has
no CSS boxes (and display: none; means no CSS boxes).

FWIW, I think it’s a bad idea to make @hidden have CSS rendering effects that
don’t fully follow from its CSS-expressible characteristics. We really don’t
need more non-CSS rendering directives in the Web platform. Trying to make
@hidden override explicit CSS-based contradictions is, IMO, in the same bad
department of speccing as HTML4 trying to suppress empty paragraphs.

In other words, I think <div hidden style="display: block !important;">This
should render in a CSS view port.</div>

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Monday, 8 October 2012 06:57:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 October 2012 06:57:25 GMT