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

Objection Summary:

1. Accessibility has not been vetted.
2. Lack of implementation.
3. Lack of styling.
4. Unknown implications of progress being a form element.
5. Behavioral user interface elements present a layering violation.

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.

However, the accessibility of the progress element has not been
thoroughly vetted or verified. The progress element currently lacks
association between action and indicator. It could be hacked with ARIA
but if such hacks are needed what is the point of the element in the
first place?

HTML5 lacks good specification of how the progress element is to be
accessible or how AT devices are to render it.

It is unknown without full investigation the impact this element will
have on accessibility. Findings from the little investigation that has
been completed is discouraging. On May 16, 2010, Shelley Powers
preliminary tested the progress element in Apple's VoiceOver.
VoiceOver seems to only audibly announce the state of the progress bar
when it first receives focus. [1]

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 the progress element indeed becomes
accessible. Accessibility should not fall through the cracks. I voted
no on the task force survey regarding the progress element. [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 the progress element is 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 progress 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, the progress
attribute should be dropped from the spec.

2. Lack of implementation.

The progress element currently lacks implementation in browsers [9]
and assistive technology. A nightly Webkit build is available. But so
far it takes about five times the amount of code to provide a progress
element than it does to use existing technologies.

The progress element 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.  Progress 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>. It is
not even a thought on HTML5 readiness charts like the one Paul Irish
and Divya Manian built [10].

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, if the
behavior is unpredictable it 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]

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 in most user
agents.

During recent testing in WebKIt [13] it was ascertained that:

* If  the background-color of the progress element is changed the
progress effect will be wiped out.
* Height or width of the progress element can not be changed. If the
progress bar's style setting is changed it adversely impacts on the
indeterminate progress bar display. You have to accept the exact
presentation of the progress bar, as determined by the browser.

It is critical for CSS to enable the progress element to be styled so
that authors can control how it is rendered. That is not the case.

4. Unknown implications of progress being a form element.

The progress element is currently a form element. It is unknown what
happens if the progress element is actually added to a form. It is not
specified if the current value is sent with other form element values
to the server application or if it isn't.

5. Behavioral user interface elements present a layering violation.

As Shelley clarified behavior is not semantics [14]. Tab's change
proposal seems to be an attempt at a fallacious or booby trapped
low-redefinition [15] of the word "semantic". Redefinition clouds the
discussion.

The issue concerns separating or mixing structure, presentation, AND
behavior in behavioral user interface elements.

Separation is architecturally sound. "A specification SHOULD allow
authors to separate content from both presentation and interaction
concerns." [16]. Keeping behavior separate and not integrating it into
elements and has served us well to date, as witness the many and
sophisticated applications we use today.

I have always used the three legged stool approach to web standards.
Separate structure, presentation, AND behavior. I have concerns if
introducing behavior into HTML is the right direction. Seems like
contamination to me...like putting presentational elements in that are
hard to get out once they are there. It is reminiscent of adding
behavior such as marquee and blink elements.

Behavioral user interface elements may be the bane of HTML5.

If behavior is not well thought out, it can 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." [17]

If widget elements are needed for accessibility, I agree with Benoit
Piette [18]. They should be completely separate them from structural
elements. Such elements could possibly go into a document of their
own, to support modularity and might be reusable in other languages.

Conclusion:

The progress 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, unknown implications of it
being a form element, and presents a layering violation.

In Jon Gunderson's no vote on the accessibility task force survey
[19], 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://realtech.burningbird.net/web/html5/progress-element-what-ive-found
[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://html5readiness.com/
[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://realtech.burningbird.net/web/html5/progress-element-what-ive-found
[14] http://www.w3.org/html/wg/wiki/ChangeProposals/removedetails#Behavior_is_not_semantics
[15] http://www.fallacyfiles.org/redefine.html#LowRedef
[16] http://www.w3.org/TR/webarch/#pci  (Architecture of the World
Wide Web, Volume One. W3C, 2004.)
[17] http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0250.html
[18] http://lists.w3.org/Archives/Public/public-html/2010May/0006.html
[19]
http://www.w3.org/2002/09/wbs/44061/200404_ftf-proposals/results#xq5

--
Laura L. Carlson