Warning:
This wiki has been archived and is now read-only.
Jfoliot/ARIA Can Only Refer To Hidden Content With Specific Restrictions
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.
Summary
There is some serious and significant misunderstanding around the entire Issue 204, which is described as:
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 forpresentation
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
orvisibility:hidden
or HTML 5hidden
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 CSSdisplay:none
orvisibility: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