This wiki has been archived and is now read-only.

Jfoliot/ARIA Can Only Refer To Hidden Content With Specific Restrictions

From HTML WG Wiki
Jump to: navigation, search

ARIA Can Only Refer To Hidden Content With Specific Restrictions

  • Author: John Foliot
  • This is a Note submitted against Issue 204. It has been edited on April 19 to remove some content, and converted from a Change Proposal to a Note, as the author has chosen to withdraw this Change Proposal against Issue 204. However, since more current Change Proposals directly reference this document, it is being preserved to support those links.


There is some serious and significant misunderstanding around the entire Issue 204, which is described as:

ISSUE-204: Exempt ARIA attributes from the rule that prohibits reference to hidden elements


Exempt ARIA attributes from the rule that prohibits reference to hidden elements


The issue of whether or not hidden content could be referenced by ARIA attributes has actually been discussed by the ARIA Working Group, as recently as March 2012.

The outcome of the ARIA WG's latest discussions has resulted in changes to the Draft ARIA Implementation Guide which speaks specifically to this Issue:

5.1.2. Excluding Elements from the Accessibility Tree

The following elements are not exposed via the accessibility API and user agents MUST NOT include them in the accessibility tree

  • Elements, including their descendents, that have host language semantics specifying that the element is hidden, such as CSS display:none or visibility:hidden or HTML 5 hidden attribute.

The net effect of this is that any hidden content referenced by an ARIA attribute will be left to render as string text only, as it is forbidden by ARIA Processing rules, as well as the various Accessibility APIs (AAPIs), to take on any other role. This is in fact consistent with how browsers are implementing this today.

For this reason, any text that is hidden but referenced by an ARIA attribute will have limited, but not zero, value to screen reader users with AAPI aware tools.

So, to the question of "Should HTML5 permit ARIA attributes to reference (point to) content that is hidden from the visual view-port of sighted users?" the answer is, it already can.

What HTML5 cannot do, what the Accessibility APIs cannot do, and what the Candidate Recommendation ARIA Specification and Draft Implementation Guide expressly forbids, is preserve any structured semantic content in a hidden element.

Even if the HTML5 Specification sought a willful violation of the ARIA Candidate Recommendation, neither the browsers nor the spec can affect the way that the Accessibility APIs (which are system level APIs) can process the content - not only is it out of scope, it is quite literally out of reach.


Positive Effects

  • ARIA shows itself to be scalable to a certain extent
  • Authors can hide small snippets of text from visual rendering, and still reference it via aria attributes

Negative Effects

  • Any content, when hidden using any of the methods of (aria-hidden, @hidden or CSS display:none or visibility:hidden), cannot support HTML-rich, structured content such as Headings, Paragraphs, List markup, Table markup, Anchor Text, or inline content (such as <span>, which could be used to support internationalization requirements: <span lang="it">peccato</span>)

Conformance Classes Changes



Without good author guidance, some authors will misunderstand the limitations of what can be achieved using ARIA. We already have evidence of that today.