hidden attribute section so it is in accord with the ARIA specification and ARIA functionality.
The HTML 5 reference to aria-describedby is inaccurate as hidden text is loaded into the accessible description string in an accessible object even though no accessible object representing the text description is exposed in the accessibility API.
Because of how APIs need to work, any hidden content referenced by an ARIA attribute is rendered as string text. The ARIA Can Only Refer To Hidden Content With Specific Restrictions change proposal explains this in detail:
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:
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
presentationrole 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
visibility:hiddenor HTML 5
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...
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.
The ARIA implementation guide requires aria-describedby populate a string description field (accDescription) and this is in fact implemented. As explained UIAG states explicitly that authors can provide strings for the accessible name and description via aria references to hidden elements, and that browsers are to process them as strings.
The fact remains that structure will be flattened to a string text. The Accessibility API mappings document explains how this is accomplished and how it results in plain string text.
Again the John Foilot's change proposal illuminates this main point:
what the Candidate Recommendation ARIA Specification and Draft Implementation Guide expressly forbids, is preserve any structured semantic content in a hidden element.
All structured semantic content in a hidden element is lost. This will lead to a very poor user experience in longer content, as reading keys will not work. Users will not be able to interact with the content. All links will be dead.
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.
Elements that are not hidden should not link to or refer to elements that are hidden.
For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. If the content is not applicable or relevant, then there is no reason to link to it.
It would similarly be incorrect to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. 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.
All HTML elements may have the hidden content attribute set. The hidden attribute is a boolean attribute. When specified on an element, it indicates that the element is not yet, or is no longer, visible or interactive. User agents should not render elements that have the hidden attribute specified.
Elements that are not themselves hidden must not hyperlink to elements that are hidden. Aria-flowto and aria-owns attributes on elements that are not themselves hidden, similarly, must not reference hidden elements.
For example, it would be incorrect to use the href attribute to link to a section marked with the hidden attribute. Since the content is not rendered, linking to it would result in behavior the user does not expect, either dropping the user at a location with no rendered content, or failing to navigate.
However, hidden elements may be used to provide descriptive plain string text, using aria-describedby and aria-labelledby and the <label> element. This technique should not be used for longer content that has structured text (e.g., headings, anchors, list markup, table markup, etc.), as accessible name and description calculation [WAI-ARIA] will flatten the referenced elements to plain text, losing interactivity and semantic structure.
<p class="note">Additionally at the time of this writing, some screen reader products will read both the accessible name and accessible description, so authors should take care with the length of text provided via this method.</p>
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.
- Corrects the HTML5 specification with what in reality, ARIA actually says and needs to do.
- Some skilled developers who use ARIA will be provided a limited technique. They can hide small snippets of text from visual rendering, and still reference it via aria-describedby and aria-labeledby.
- Authors are told to not use a technique that does not work, e.g., hidden cannot support HTML-rich, structured content such as headings, paragraphs, list markup, table markup, anchor text, or inline content (such as <span>).
- See Risks.
Conformance Classes Changes
- No change.
- Some authors will misunderstand the limitations of what can be achieved using ARIA, and will point aria-describedby to hidden structured text. Structure will be flattened to a string text and that string will populate the accessible description field in the accessibility API. This will lead to a very poor user experience in longer content, as reading keys will not work. Users will not be able to interact with the content. All links will be dead.
- Possessing this special ARIA clause (instead of simply reinforcing the concept that "hidden always means hidden" as the spec currently does) adds complexity to the spec and will cause some authors, especially novice authors, confusion.
Sub-Pages for this Proposal
- 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