Warning:
This wiki has been archived and is now read-only.
ChangeProposals/AllowAriaReferHidden
Allow ARIA Attributes to Reference Hidden Elements
This is a Change Proposal for ISSUE-204
(This Change Proposal was originally for ISSUE-30 and titled "Keep the longdesc attribute for the img element deprecated" and has been updated in response to the HTMLWG Chairs' decision to split ISSUE-30 into two separate issues.)
Summary
Because authors sometimes need to provide a complex description of a page element for users of Assistive Technology without any forced visual encumbrance or default visual indicator, HTML should allow this to be done in the most straightforward manner, by enabling aria-describedby=""
to point at elements hidden with the hidden=""
attribute.
Rationale
Web authors often wish to provide a description of a complex element only to screen reader users, while hiding the description from all other users. Being able to provide such a description without any forced visual encumbrance or default visual indicator is a frequently-cited accessibility requirement. Consider the following markup:
<pre role=img aria-describedby=foo> )\._.,--....,'``. fL /, _.. \ _\ ;`._ ,. `._.-(,_..'--(,_..'`-.;.'</pre>
<p id=foo hidden>An ASCII art rendition of a cat in prone position.</p>
This example contains an ASCII art rendition of a cat inside a <pre>
element. A description of the art is provided for AT users. By using aria-describedby=""
to point at a hidden=""
element, the web page author avoids any forced visual encumbrance or default visual indicator.
The hidden=""
attribute is the simplest, most straightforward mechanism for hiding elements in HTML or CSS. Given this, authors are likely to use it to hide long descriptions. The WAI-ARIA specification allows aria-describedby=""
to point at non-visible content, so it is reasonable for authors to expect such markup to function properly. Because authors rarely run their content through conformance checkers, authors are likely to point at hidden=""
content from aria-describedby=""
whether or not we forbid them from doing so.
The authoring restriction on what sort of hidden=""
elements may be referred to from WAI-ARIA attributes is intentionally not machine-checkable: implementations are a moving target; going forward, we expect more UA and AT implementations to expose the full semantics of hidden=""
elements. Given this, testing the appropriateness of content is best left to linters or similar tools, which can be updated faster than specifications.
Feedback from Browser Implementers
Two people working for browser implementers have suggested that exposing hidden elements in the accessibility tree is feasible, and similar to the work already under way to expose hidden child elements of the <canvas>
element:
I don't think Apple has a strong stance either way on using @aria-describedby to point to @hidden elements, but I believe we could reasonably expose full semantics of hidden content pointed to by aria-describedby, this is more or less the same as the work we'd have to do to expose <canvas> children as an accessible tree.
In firefox, the reason that @hidden elements are "stringified" whenexposed through aria-describedby is because they don't have CSS boxes. This is also why we have problems currently when exposing the contents of a <canvas>. In both cases the accessibility code "fails" because it tries to use the CSS boxes which aren't there. Hence the fallback to
stringify.
Exposing the rich semantics of contents inside a <canvas> in Firefoxwill take a lot more than changing what object <canvas> inherits from. Whatever solution we come up with for that can hopefully be reused to expose the rich contents of @hidden elements exposed through
aria-describedby.
We now have two implementations which say that exposing the richcontents of @hidden elements pointed to using aria-describedby is
implementable. And is implementable without changes from AT vendors.
Details
Replace
All HTML elements may have thehidden
content attribute set. Thehidden
attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, relevant. User agents should not render elements that have thehidden
attribute specified.
with
All HTML elements may have thehidden
content attribute set. Thehidden
attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, directly relevant to the page's current state, or that it is being used to declare content to be reused by other parts of the page as opposed to being directly accessed by the user. User agents should not render elements that have thehidden
attribute specified.
Replace
Elements that are nothidden
should not link to or refer to elements that arehidden
.
with
Elements that are not themselveshidden
must not hyperlink to elements that arehidden
. Thefor
attributes oflabel
andoutput
elements that are not themselveshidden
must similarly not refer to elements that arehidden
. In both cases, such references would cause user confusion. Elements and scripts may, however, refer to elements that arehidden
in other contexts.
Replace
It would similarly be incorrect to use the ARIAaria-describedby
attribute to refer to descriptions that are themselveshidden
. Hiding a section means that it is not applicable or relevant to anyone at the current time, so clearly it cannot be a valid description of content the user can interact with.
with
It would be fine, however, to use the ARIAaria-describedby
attribute to refer to descriptions that are themselveshidden
. 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. Similarly, acanvas
element with thehidden
attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hiddenform
element using itsform
attribute.
Additionally, add the following paragraph to #the-hidden-attribute
:
User Agents are encouraged to expose the full semantics ofhidden=""
elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such asaria-describedby=""
. However, because historically some User Agents have flattened hidden content when exposing such content to Assistive Technology, authors SHOULD NOT reference hidden content which would lose essential meaning when flattened.
Impact
Positive Effects
- Provides a simple, consistent way for UAs to hide content from sighted users while exposing it to screen reader users. This is an advantage over traditional ways of hiding AT-specific content using CSS to position content offscreen.
- Provides an intuitive way for authors to hide content from sighted users. If you want your description to not be visible, put a hidden attribute on it, just like other contents that you don't want to be visible by default.
Negative Effects
- None
Conformance Classes Changes
- No change.
Risks
- None
References
References are linked inline.
Contributors
- Jonas Sicking, Matt Turvey, Edward O'Connor, (editorial changes) Sam Ruby