Rationale for aside Element Issue 91 Straw Poll is attached.
--
Laura L. Carlson
For aside Element Issue 91 Straw Poll
http://www.w3.org/2002/09/wbs/40318/issue-91-objection-poll/results
OBJECTION SUMMARY:
1. Accessibility has not been vetted.
2. Lack of implementation.
3. Lack of styling.
4. Added complexity and ambiguity.
OBJECTION DETAILS:
1. Accessibility has not been thoroughly vetted or verified.
Creating elements that are inherently accessible, that provide
accessibility from the get-go, with no additional work by the author
is could be a win for accessibility. A mechanism to provide a native
aside element ala the WAI-ARIA "complimentary" landmark role [1] is a
good idea. It could be applied to an area containing associated
content.
However, the accessibility of the aside element has not been
thoroughly vetted or verified. In Tab's change proposal he said that
the aside element "expresses this semantic directly in the markup,
allowing other types of UAs to give their users similar ability to
skip over irrelevant content and return to it at their leisure".
HTML5 lacks good specification of how devices are to interact with
aside and skip the content.
The elephant in the room is keyboard access. Sure skip links are
incredibly arcane but where is the keyboard support for the aside
element?
It seems to be close, but verification is needed to ensure the element
is mapped correctly.
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).
One of several examples [2] 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 [3].
Multimedia requirements are only now being to be discussed [4] in the
task force.
The Accessibility Task Force resolution on aside proclaimed, "We
maintain the work item to check these elements and make them better."
[5]
However, to date no action-plan or timetable or volunteers exist, that
I am aware of, to ensure that the aside element is indeed accessible.
Accessibility should not fall through the cracks. I voted no on the
task force survey regarding these features. [6] My comment included:
"The resolution states: "We maintain the work item to check these
elements 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 [7] 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 the aside element is to be included the spec, it should be
accessible I would remove point one of this objection if the proposed
action plan [8] or something similar was adopted and the task force
fulfilled their commitment to make the element 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 of making the
aside element better, it should be dropped from the spec.
2. Lack of implementation.
Aside lacks implementation in browsers and assistive technology [9].
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. Aside 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 [10], "
Creation of orphaned, poorly implemented or non-implemented elements
is not the goal. Having rich semantics that do not require an
accessibility api to function (not all people with disabilities use
AT) is laudable. But, only if implemented. Current implementations -
0, aria workarounds - 5".
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". [11]
3. Lack of styling.
Native elements that are not styleable to suit the aesthetic desires
of developers and marketing departments will not be used. Elements
that are not used are not needed in the spec. They are excess baggage.
Internet Explorer refuses to apply styles to aside or allow it to be
used as part of CSS selectors. A hack is available but it is a perfect
example of the problems developers face with the introduction of this
element.
4. Added complexity and ambiguity.
The figure element is confusing. As Shelley delineates in her Change
Proposals, the definitions of the aside and figure sound almost
identical, except that figure has a caption. They are not only
uncomfortably generic but also dangerously close in meaning, which
adds complexity and ambiguity. This is a symptom of a spec that
doesn't do its job.
Developers will tend to confuse the two elements and use them
incorrectly. It will present a challenge for educators to teach the
difference.
The more choices you give people, the harder it is for them to choose,
and the more likelihood of them getting it wrong. Many times it is not
any given feature that causes problems; it's having too many choices
or overlapping meanings, which adds complexity and leads to confusion.
In contrast narrower choices leads to clarity, which leads to getting
it right. This is akin to the spec not including <acronym> and
deferring to <abbr>.
"The Paradox of Choice: Why More Is Less" (Barry Schwartz; Ecco, 2003)
shows that a bewildering array of choices floods a person 's brain,
ultimately restricting instead of freeing. We normally assume that
more options ('easy fit' or 'relaxed fit'?) will make us happier, but
Schwartz demonstrates the opposite is true. Too many choices actually
makes things more difficult. Hick's Law (Hick, William E.; On the rate
of gain of information. Quarterly Journal of Experimental Psychology,
4:11-26, 1952) states the time it takes to make a decision increases
as the number of alternatives increases.
More choice (aside as currently defined in the spec) equals more time
required, more anxiety, more errors, and difficult learnability.
Some developers may want more choices and complex levels of control.
But they don't want the complexity that entails elements that are
ambiguous, error prone, or difficult to learn. Simple design doesnÕt
mean featureless: it means being as simple as necessary to achieve an
outcome.
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.
CONCLUSION:
The aside element is insufficiently thought out. Or as Leif has termed
such things, it is "half baked". It has unvetted accessibility, lack
of implementation, lack of styling, and added complexity and
ambiguity.
In Jon Gunderson's no vote on the accessibility task force survey
[12], 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/TR/wai-aria/roles#complementary
[2] http://www.w3.org/html/wg/wiki/HTMLRequestsPFresponse
[3] http://lists.w3.org/Archives/Public/public-html/2008Sep/0421.html
[4] http://lists.w3.org/Archives/Public/public-html-a11y/2010May/0084.html
[5]
http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0183.html
[6]
http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5
[7] http://www.w3.org/WAI/PF/HTML/track/
[8] http://lists.w3.org/Archives/Public/public-html/2010Apr/1301.html
[9]
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29#Elements
[10] http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5
[11] http://lists.w3.org/Archives/Public/public-html/2008Jun/0140.html
[12]
http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5
--
Laura L. Carlson
