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

Review of Section 7.1 by ARIA working group in PF

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Mon, 1 Oct 2012 11:07:39 -0500
To: public-html-a11y@w3.org, janina@rednote.net
Cc: w3c-wai-pf@w3.org, faulkner.steve@gmail.com
Message-ID: <OF7FED8AF7.F9885423-ON86257A8A.005738F1-86257A8A.0058AB52@us.ibm.com>

I would like to discuss these points on this weeks HTML accessibility task
force call. There is a concern that some of the text will confuse authors.

1. We read this text and we don't believe this text was agreed upon by
anyone and we have doubts this is enforceable:

"The hidden attribute must not be used to hide content that could
legitimately be shown in another presentation. For example, it is incorrect
to use hidden to hide panels in a tabbed dialog, because the tabbed
interface is merely a kind of overflow presentation — one could equally
well just show all the form controls in one big page with a scrollbar. It
is similarly incorrect to use this attribute to hide content just from one
presentation — if something is marked hidden, it is hidden from all
presentations, including, for instance, screen readers."

From an accessibility perspective it does not really hurt us but if it were
actually enforceable it would frustrate authors who want to use hidden over
CSS display:none. This will just cause authors to not use this feature of
HTML5. There are lots of other examples of this, menus hidden at the bottom
of the page, etc. Futhermore, how are most authors going to know what the
user agent is going to hide to a screen reader?

2. This text is incredibly vague and because it is so I don't have an issue
with it and because ARIA 1.0 does allow stripping semantics to produce the
text strings I don't have an issue. Developers who actually read this will
just shake their head and move on:

"While hiding the descriptions implies that they are not useful alone, they
could be written in such a way that they are useful in the specific context
of being referenced from the images that they describe."

3. This API features is only available in IA2 and ATK/ATSPI today and even
then the only browser that supports these two APIs does not expose hidden

"Accessibility APIs are encouraged to provide a way to expose structured
content while marking it as hidden in the default view. Such content should
not be perceivable to users in the normal document flow in any modality,
whether using Assistive Technology (AT) or mainstream User Agents."

The ARIA working group should try to address whatever the editors would
like to see here in the ARIA 1.1 time frame, providing Apple and Microsoft
are able enhance their accessibility API in that time frame. There will
also be issues about exposing hidden content that Mozilla will also need to

4. This text refers to content being active but what is not clear is
whether "active" hidden text would appear in the tab order. We don't
believe that is the case  but it needs to be stated somewhere. Also, the
text for active refers to form controls (which are normally found in the
tab order). Is the intent to only address form controls and should that
somehow should be restated here? For example, what happens when you have
<div tabindex="0" hidden>. Does the div appear in the tab order?

"Elements in a section hidden by the hidden attribute are still active,
e.g. scripts and form controls in such sections still execute and submit
respectively. Only their presentation to the user changes."

Janina, please add this to the agenda.


Rich Schwerdtfeger
Received on Monday, 1 October 2012 16:09:37 UTC

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