Re: ISSUE-95 Change Proposal

Thanks for providing a Change Proposal for this issue! The chairs  are  
reviewing Change Proposals to ensure that they meet the required  
structure. Here is our feedback on this Change Proposal (actually the  
version subsequently uploaded to the wiki):

(1) This Change Proposal includes all of the required sections with  
appropriate content. The Rationale and Details sections seem sufficient.

We believe this Change Proposal is well-formed and ready for  
consideration by the Working Group.

Regards,
Maciej

On Mar 31, 2010, at 6:34 AM, Shelley Powers wrote:

> 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 Tuesday, 6 April 2010 20:21:32 UTC