ARIA Can Only Refer To Hidden Content With Specific Restrictions

Summary

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

aria-hidden

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

Details

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 with role="presentation" according to the rules for presentation role defined in Accessible Rich Internet Applications (WAI-ARIA) 1.0.

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

Impact

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

None.

Risks

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

References

• Accessible Rich Internet Applications (WAI-ARIA) 1.0 (W3C Candidate Recommendation)
• WAI-ARIA 1.0 User Agent Implementation Guide (W3C Editor's Draft)
• Action-970 (PF) Publish F2F Minutes Extract RE ARIA-Describedby