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

ChangeProposals/CorrectHidden

From HTML WG Wiki
Jump to: navigation, search


Correct the hidden Attribute Section to be in Accord with the ARIA Spec

This is a Note submitted against Issue 204. It was last edited on May 1, 2012. Although the author still worries that possessing special ARIA language (instead of simply reinforcing the simple concept that "hidden always means hidden" as the HTML5 spec currently does) adds complexity to the spec and will cause some authors, especially novice authors, confusion, she has chosen to withdraw it in deference to Cynthia's stabilized proposal (id=12821) as long as that proposal makes no further changes and remains stable, as it seems to bring HTML5 and ARIA in accord on this issue and illuminates normatively the fact that accessible name and description calculation (WAI-ARIA) flattens the referenced elements to plain text, losing interactivity and semantic structure.

Summary

Correct the hidden attribute section so it is in accord with the ARIA specification and ARIA functionality.

Rationale

As Richard Schwerdtfeger succinctly stated on April 9, 2012:

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:

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

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.

Details

Remove

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.

Add

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>


Remove

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.

Impact

Positive Effects

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

Negative Effects

  • See Risks.

Conformance Classes Changes

  • No change.

Risks

  • 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

References