Rationale for figure Element Issue 90 Straw Poll is attached.
--
Laura L. Carlson
For figure Element Issue 90 Straw Poll
http://www.w3.org/2002/09/wbs/40318/issue-90-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
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
