ISSUE-95 Change Proposal

Summary

    Summary: Remove the hidden attribute. Its functionality is already
fulfilled by the use of CSS and ARIA attributes. It is redundant, and
its inclusion in HTML5 introduces inconsistent and non-complementary
directions from the W3C.

Rationale

The rationale given by the HTML5 Editor for rejecting this change was:

   "Rationale: hidden="" is a key part of HTML5's accessibility story and
    represents one of the main accessibility improvements over HTML4 for dynamic
    applications."

Though not given in the bug rejection, the HTML5 specification also
provides another semantic rationale for hidden that others brought up
in the associated bug thread[1]:

    When specified on an element, it indicates that the element is not
yet, or is no longer, relevant.


Summarizing the rationales given, then, for keeping the hidden
attribute, we have:

    * It is necessary for accessibility

    * It is semantic

Taking these, one at a time:

The HTML5 Editor did not specify why the hidden attribute was one of
the most important accessibility improvements. I'm therefore forced to
guess the reasoning.

>From my understanding, in the past, screen readers were not always
consistent about how they responded to the display and visibility CSS
attribute settings. Thought the readers may not read out values that
were set to display:none or visibility:hidden when the page loads,
changing these properties dynamically wouldn't always trigger the
screen reader to be aware of the contents of the newly exposed
element.

This situation has since improved with the advent of WAI-ARIA, and the
aria-hidden attribute[2]. This attribute removes any confusion about
the purpose of hiding or not displaying an element: if the aria-hidden
attribute is set to true or an element, the screen reader is to
disregard it, as if it isn't part of the DOM; when it is set to false,
the screen reader is to render the element's contents. Therefore, a
combined use of setting the CSS display to none (or visibility to
hidden) and aria-hidden works to ensure that the content is rendered
correctly regardless of user agent. The use of aria-hidden/CSS also
doesn't require the introduction of a new attribute, and is a
technique that can be used safely and with confidence today, rather
than at some future time. To ensure that both values are in sync, the
CSS properties can be changed based on the aria-hidden attribute
value:

[aria-hidden="true"] { display: none }

When the aria-attribute value is changed, the CSS property is set,
accordingly. If people are concerned that the CSS attribute selector
isn't universally supported in all browsers yet,  we can easily set
both the CSS style property at the same time as the aria-hidden
attribute is set—the technology exists, is uncomplicated, and all
that's necessary is to educate web developers to use aria-hidden in
addition to the CSS in their dynamic applications.

The use of aria-hidden is now being incorporated into popular
libraries, such as jQuery, and in particular jQuery UI. AOL has newly
directed the Paciello Group[3] to aid in the effort of further
integrating the ARIA states and roles into jQuery UI, so that
developers may continue using the exact same library they're using
now, but the effect will be 100% accessible.

Incorporating material from a separate domain, in this case ARIA for
accessibility, is the direction web developers, designers, template
makers, and other application builders are comfortable following. All
our widgets are developed using technologies from three domains:
JavaScript, CSS, and HTML. Introducing single-purposed elements and
attributes in HTML5 introduces a jarring note of incompatibility.

The second rationale for the hidden element is that it serves a
semantic purpose. From discussions about this element on the WhatWG
email list, I found the following exchange between the HTML5 editor,
Ian Hickson, and another individual. In the exchange, Ian is
responding[4]:

--

> If the true purpose of the irrelevant attribute is to aid in
> accessibility, then I think the name is completely wrong. The term
> "irrelevant" is confusing because, as I stated before, why would anyone
> include content in a page that is irrelevant? What you really need is a
> way to say "this is relevant only for non-visual UA's". Perhaps a better
> attribute name would be "nonvisual"?

The "true" purpose is to separate the structure and semantics from the
presentation. "Accessibility" (and "Internationalisation" and "Security"
and "Performance") isn't a purpose, it's just a design technique.

--

The "true" purpose is to separate the structure and semantics from the
presentation. Yet the HTML5 specification's definition of this
attribute is primarily focused on its presentational aspect. For
instance, the following:

"Elements in a section hidden by the hidden  attribute are still
active, e.g. scripts and form controls in such sections still execute
and submit respectively. Only their presentation to the user changes."

There's an inconsistency in how hidden is described. The specification
states that an element with a hidden attribute is one that's
supposedly not relevant or no longer relevant. But then the HTML5
specification mentions that the section is still active, that form
controls that are hidden can still be submitted or actions executed on
elements, and so on. That, to me, means then that the section is
relevant: visible or not, displayed or not, it's still participating
in the page actions, therefore it is relevant.

The only truly irrelevant page component is one that doesn't exist. If
people want a truly irrelevant page section, they should use the DOM
to create and remove the element, as needed. There is nothing about
the behavior associated with removing an element from user agent
rendering that is made more meaningful using a single-purposed HTML
attribute, rather than using a simple combination of CSS property and
ARIA attribute. Both have to do with the presentation of the element.

Contrary to assertions, presentation with hidden isn't an incidental
purpose, it is the primary purpose of the attribute. Rather than
separate presentation and structure, it firmly welds the two, and in
the process sets a precedent for additional single-purposed
elements/elements that undermine all of the effort taken in the last
decade to separate presentation and structure.

The hidden attribute also undermines the WAI-ARIA effort, leading to
confusion about the direction that developers are supposed to follow.
This at a time when ARIA is beginning to make inroads in the existing
JavaScript libraries, such as jQuery UI, Dojo, Google Web Toolkit,
Yahoo! User Interface (YUI), and others[5]. What are we telling
people? That they should continue incorporating CSS/ARIA into their
widgets and libraries, which works now? Or that they should use
CSS/ARIA now, and then at some time in the future, use the hidden
attribute, but only for specific display/hide behavior, and use
CSS/ARIA for everything else?

Providing two different and not complementary directions for the same
effect impacts negatively on the credibility of both, and on the
organization that's proposing them. This seemingly inconsistent
direction from the W3C will only result in web developers ignoring all
of it, to the detriment of both semantics, and accessibility.

Details

Remove the hidden attribute. Based on the March 4th Heartbeat Document[5]:


    * Remove the reference to the hidden attribute in 3.2.3.7.

    * Remove the reference to the hidden attribute in 4.10.20.2.

    * All references to the hidden state throughout the document, if
such is related to the hidden attribute

    * Remove Section 7.1 and all references to Section 7.1

    * Remove the reference to the hidden attribute in Section 10.1


Impact

Positive Effects

This removes an inconsistent approach for hidden content that can
cause confusion to developers about which direction to follow for
accessibility. This also removes a redundant attribute, helping to
simplify the HTML5 specification. It also halts the new precedent
being set in HTML5, that we should replace the currently encouraged
separation of presentation and structure, with single purposed
attributes/elements.

For browser developers and other user agents, this change reduces the
need to support an HTML5 attribute, in addition to CSS and ARIA states
that perform the exact same behavior. HTML editors will have one less
new HTML5 entity to worry about implementing. Authors, developers, and
designers will have a clear direction to follow for element display
and visibility

Negative Effects

It will take Editor time to implement the change. However, this is
balanced with the hundreds, perhaps thousands of hours necessary to
implement this attribute in user agents. And since this attribute has
not been implemented yet, there is no other negative cost to the
change.

References


[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8118

[2] http://www.w3.org/TR/wai-aria/states_and_properties#aria-hidden

[3] http://www.paciellogroup.com/blog/?p=566

[4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-August/016027.html

[5] http://www.paciellogroup.com/blog/?p=313

-------------------

Shelley Powers
http://realtech.burningbird.net

Received on Wednesday, 31 March 2010 13:34:50 UTC