For figure Element Issue 90 Straw Poll
http://www.w3.org/2002/09/wbs/40318/issue-90-objection-poll/results

Figure Element

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 hooks from the get-go, with no additional work by the
author is could be a win for accessibility.

A mechanism to explicitly provide a caption for an image is a good idea.

However, the accessibility of the figure/figcaption elements has not
been thoroughly vetted or verified.

HTML5 lacks consideration of how figure/figcaption is to be accessible
and how AT devices are to interact with it.

1.1. The majority of style guides disallow tables as content for a
figure [1]. But HTML5 does not. It allows any flow content in the
figure element not just images. This may present a problem.

Assistive technology issues of embedding a table into a figure are
unknown. It adds complexity without considering repercussions.

How would nesting a table into figure affect table reading keys? Do
any issues exist with a figcaption + table caption scenario? A table
caption is read by JAWS. Will a figcaption be read in the same way?
Would one take precedence over the other if they are both included?
Would one be read and not the other?

How would multiple tables in a figure element be read? It seems that
they should linearize correctly but would they?

1.2. The spec does not define how the figure is associated with the
original content. Tab's change proposal states,

"Users interacting visually with the article can easily skip past this
content temporarily and avoid interrupting their reading of the main
article, and then return to the content to understand it when they
feel comfortable. Expressing this semantic directly in markup allows
alternative UAs to present their users with the same ability, thus
improving Accessibility."

The spec does not say devices should have the ability to skip over the
figures, and return later, which would be useful. The figure element
could be located outside of an article; it could be located in another
part of the web page, even another web page. It is not specified how a
connection between this physically separated element is relate back to
the original article element.

The spec does not specify how this is to be accomplished in a device
independent way.

It is unknown without investigation the impact this element 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 [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 April 20, 2010 Accessibility Task Force resolution 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 these new features do indeed become
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 figure/figcaption elements are included the spec, they 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, the figure and
figcaption elements should be dropped from the spec.

2. Lack of implementation.

The figure and figcaption elements currently lack implementation in
any browser [9] [10] or assistive technology. As Jim Allan said on the
accessibility task force survey, "Creation of orphaned, poorly
implemented or non-implemented elements 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 figure and figcaption elements are 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.  Figure 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>.

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.
Default rendering and graceful degradation are unknown.

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. Bad complexity leads to frustration, wasted time
and wasted money.

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 and unmistakable definition 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 (figure and 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 figure element is insufficiently thought out or as Leif has termed
such things "half baked". It has unvetted accessibility, lack of
implementation, lack of styling, and adds complexity and ambiguity to
HTML5.

In Jon Gunderson's no vote on the accessibility task force survey
[13], 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://lists.w3.org/Archives/Public/public-html/2009Dec/0016.html
[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://dev.w3.org/html5/alt-techniques/#altmethod
[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/2002/09/wbs/44061/200404_ftf-proposals/results#xq5

-- 
Laura L. Carlson