For hidden Attribute Issue 95 Straw Poll
http://www.w3.org/2002/09/wbs/40318/issue-95-objection-poll/results

OBJECTION SUMMARY:

1. Accessibility has not been vetted.
2. Lack of implementation.
3. Layering violation.

OBJECTION DETAILS:

1. Accessibility has not been thoroughly vetted or verified.

Creating attributes that are inherently accessible with no additional
work by the author could be a win for accessibility.

However, the accessibility of the hidden attribute has not been
thoroughly vetted or verified. Example problems that have been brought
up are significant [1].  The precedence ordering of all combinations
of aria-hidden, display="none", and hidden="" are not specified.

A HTML hidden attribute may or may not have the same types of problems
as CSS display: none does [2]. We don't know.

It is unknown without investigation the impact this attribute will
have on accessibility.

Not considering accessibility at the design stage has been a big
mistake for new HTML5 features.  As we all know, considering
accessibility/bolting it on after the fact is problematic not to
mention time consuming (e.g. canvas and video).

It takes time to fully vet the accessibility of a feature. One of
several examples [3] of the time it takes to merely get a topic on the
WAI agenda: In 2008 I first requested that PFWG WAI review multimedia
<audio> and <video> accessibility requirements [4]. Multimedia
requirements are only now being to be discussed [5] in the task force.

The April 20, 2010 Accessibility Task Force resolution proclaimed, "We
maintain the work item to check these elements and make them better."
[6]

However, to date no action-plan or timetable or volunteers exist, that
I am aware of, to ensure that the hidden attribute indeed becomes
accessible. Accessibility should not fall through the cracks. I voted
no on the task force survey regarding these new features. [7] My
comment included: "The resolution states: "We maintain the work item
to check these attributes and make them better. How would this work?
Do we have volunteers to do this?" as I knew I didn't have the cycles.

The **Official** Task Force Work Tracker [8] has no work item being
maintained to insure these features are made better. There are no
volunteers that I am aware of. There is no plan, which I am aware of,
for the Task Force to follow through on their promise.

If hidden is to be included the spec, it should be accessible.

I would remove point one of this objection if the proposed action plan
[9] or something similar was adopted and the task force fulfilled
their commitment to make the attribute better, so that that the HTML
Working Group can be assured that it has satisfied accessibility
dependencies.

If the task force does not have an official and trackable plan, the
time, or the volunteers to fulfill their commitment, the hidden
element should be dropped from the spec.

2. Lack of implementation.

The hidden attribute lacks implementation any browser or assistive
technology[10]. It is currently unproven. As the decision for issue 76
stated, "being unproven is not necessarily a strong objection to
inclusion by itself, but it's worth considering along with other
factors."  If it turns out to cause problems in the future, it would
be unfortunate to have the HTML5 spec encumbered with it. Hidden is
one of the least mature features in the HTML5. It does not have the
maturity level of features inherited from HTML4, or even newer but
widely implemented functionality such as <canvas> or <video>.

As Jim Allan said on the accessibility task force survey, "Creation of
orphaned, poorly implemented or non-implemented attributes is not the
goal". [11]

In many cases assistive technology is an interface between a user with
disability and the technology a user with no disability will use to
browse the Web. So the behavior of such assistive technology will
depend on the output given by a conventional Web browser. And if the
conventional Web browser is challenged in rendering a Web content, the
challenge will pass on to the assistive technology. In the end, the
behavior is unpredictable and may be unusable.

As Ian Hickson has said, "default state for a feature request is for
it to be rejected and the default state for a section of the spec was
for it to be eventually dropped unless the feature is widely
implemented and so important that browser vendors are actually ready
to commit money and risk interop issues over it". [12]

The hidden attribute may or may not have the same implementation
repercussions CSS for hiding content [13]. We do not know. If there is
anything wrong with CSS for hiding content, the CSS working group
should address it. Adding a hidden attribute to HTML is a bandaid
approach.

3. Adding the hidden attribute presents a layering violation.

This point concerns mixing presentational utility into HTML.

The hidden attribute indicates that the item exists but should not be
rendered. The spec says that only the *presentation* to the user
changes for elements in a section hidden by the hidden attribute. This
is the realm of CSS.

Separation is architecturally sound. "A specification SHOULD allow
authors to separate content from both presentation and interaction
concerns." [13].

I have always used the three legged stool method of web standards.
Separate structure, behavior, AND presentation. I have concerns if
introducing presentation into HTML is the right direction. Seems like
contamination to me...putting presentational attributes in that are
hard to get out once they are there. It is reminiscent of adding
<font>. The main benefit of CSS is that it separates presentation. By
adding the hidden attribute we lose a clean separation.

Integrating a CSS utility into HTML is duplication of effort. If not
well thought out it could be a disaster. As Ian Hickson has said,
layering violations "lead to complicated interdependencies. These tend
to snowball as the technology matures. Layering violations are
actually one of the most insidious problems in language design,
because they appear innocuous at first, and tend to accrete over time,
leading eventually to a disaster." [14]

Every element and attribute adds complexity to the language. Simple
design doesnŐt mean featureless: it means being as simple as necessary
to achieve an outcome. And if that outcome can be achieved cleanly
through another spec, the more efficient HTML5 will be.

Simplicity is treading a line. Antoine de Saint-Exupery said, "In
anything at all, perfection is finally attained not when there is no
longer anything to add, but when there is no longer anything to take
away." It comes across as magic when it works. That is a high
achievement.  It is what HTML5 should aim for.

However, *if * a hidden attribute is required for accessibility and
*if * it is decided that modularity is to be discounted, adding hidden
should be coordinated not only with PFWG for ARIA but with the CSS
working group so all three specs can be harmonized. Some type of super
cascade may need to be considered.

CONCLUSION:

The hidden attribute is insufficiently thought out or as Leif has
termed such things: "half baked". It has unvetted accessibility, lack
of implementation, and presents a layering violation.

In Jon Gunderson's no vote on the accessibility task force survey
[15], he commented, "I think the more we can simplify HTML 5 elements
the easier it will be to get HTML 5 and accessibility implemented and
to explain to authors how to create accessible content in HTML5.
Browser developers will probably not implement these elements anyway
if they don't like them or do it inconsistently. There is a lot in
HTML5 and I think we have enough to discuss without spending time on
elements that may never be implemented." I agree.

REFERENCES:

[1] http://www.w3.org/html/wg/wiki/ChangeProposals/removehidden#Accessibility
[2] http://juicystudio.com/article/screen-readers-display-none.php
[3] http://www.w3.org/html/wg/wiki/HTMLRequestsPFresponse
[4] http://lists.w3.org/Archives/Public/public-html/2008Sep/0421.html
[5] http://lists.w3.org/Archives/Public/public-html-a11y/2010May/0084.html
[6]
http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0183.html
[7]
http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5
[8] http://www.w3.org/WAI/PF/HTML/track/
[9] http://lists.w3.org/Archives/Public/public-html/2010Apr/1301.html
[10] http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29#Global
[11] http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5
[12] http://lists.w3.org/Archives/Public/public-html/2008Jun/0140.html
[13] http://www.w3.org/TR/webarch/#pci (Architecture of the World Wide
Web, Volume One. W3C, 2004.)
[14] http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0250.html
[15] http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5

--
Laura L. Carlson
-- 
Laura L. Carlson