Difference between revisions of "ChangeProposals/AllowAriaReferHidden"

From HTML WG Wiki
Jump to: navigation, search
m (linters)
(make sure we don't lose the fixed typo when applying this change)
Line 60: Line 60:
 
== Details ==
 
== Details ==
  
Revert the change made at the request of the Chairs in http://html5.org/r/6980 to make the W3C HTML5 spec consistent with the WHATWG HTML spec.
+
Revert the change made at the request of the Chairs in [http://html5.org/r/6980 r6980].
 +
 
 +
Fix the typo (in the <code>translate=""</code> attribute section) that was fixed in [http://html5.org/r/6980 r6980].
  
 
Additionally, add the following paragraph to <code>#the-hidden-attribute</code>:
 
Additionally, add the following paragraph to <code>#the-hidden-attribute</code>:

Revision as of 17:52, 24 July 2012


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.

Maciej Stachowiak, Apple

In firefox, the reason that @hidden elements are "stringified" when

exposed 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 Firefox

will 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 rich

contents of @hidden elements pointed to using aria-describedby is

implementable. And is implementable without changes from AT vendors.

Jonas Sicking, Mozilla

Details

Revert the change made at the request of the Chairs in r6980.

Fix the typo (in the translate="" attribute section) that was fixed in r6980.

Additionally, add the following paragraph to #the-hidden-attribute:

User Agents are encouraged to expose the full semantics of hidden="" elements to Assistive Technology when such elements are referenced from WAI-ARIA attributes such as aria-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.

While the following is believed to be an accurate description of the changes that would result in reverting r6980, the requested change is simply to revert r6980 and to add the above paragraph.

In 7.1 The hidden attribute

Before

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, relevant. User agents should not render elements that have the hidden attribute specified.

After

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, 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 the hidden attribute specified.


Before

Elements that are not hidden should not link to or refer to elements that are hidden.

After

Elements that are not themselves hidden must not hyperlink to elements that are hidden. The for attributes of label and output elements that are not themselves hidden must similarly not refer to elements that are hidden. In both cases, such references would cause user confusion.

Elements and scripts may, however, refer to elements that are hidden in other contexts.


Before

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.

After

It would be fine, however, to use the ARIA aria-describedby attribute to refer to descriptions that are themselves hidden. 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, a canvas element with the hidden attribute could be used by a scripted graphics engine as an off-screen buffer, and a form control could refer to a hidden form element using its form attribute.

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