ISSUE-96 Change Proposal

Summary

    Summary: Remove the progress element.

Rationale

In the bug associated with this issue[1], the HTML5 editor, Ian
Hickson wrote as rationale for turning down the change request:

    "Rationale: <progress> fixes a serious accessibility problem with
dynamic apps,
    and accessibility is important."

I have to make a guess about what serious accessibility problem
progress solves, since the editor did not specifically state it. I'm
assuming the problem is the fact that the information given visually
by the progress bar is not vocalized by screen readers.

According to the HTML5 specification, there are two types of progress
element: indeterminate, like a throbber, and determinate, like a
progress bar. The indeterminate progress element is like the many
we've seen in web pages—it's a simple animated graphic that basically
implies, "working...". The determinate progress bar is like those
we've seen where a bar is filled in from let to right, the amount
filled in representing the completion status of a task.

Something like a progress element is useful...which is why we've had
graphical and JavaScript/CSS based progress indicators for over ten
years now. I created my first progress bar using a small GIF element
and a timer close to 15 years ago for my first book on JavaScript.

Addressing the individual types of progress element, beginning with
the indeterminate: there are indeterminate progress graphics that spin
and pulse, and twitch about, all with an alt text along the lines of
"The task is in process", or the like. There is absolutely nothing
that the indeterminate state of the progress element provides that we
don't already have, and yes, which is accessible, too. More
accessible, as there is nothing in the specification about the element
that specifically addresses accessibility. If we want more, though, we
can also annotate the progress indicator with WAI-ARIA values, as
discussed next.

I'm assuming that the greater concern about progress indicators is
related to the second of the progress element types, the determinate
progress bar, which provides indication of how far along the task is,
and how far it has to go. As Mozilla demonstrated[2] some time ago,
though, we've had accessible progress bars for some time now, thanks
to the WAI-ARIA effort. In particular, the use of
role="progressbar"[3], with associated ARIA states, aria-valuenow[4],
aria-valuemin[5], aria-valuemax[6], and the optional
aria-valuetext[7], provide all the information that's necessary to
ensure that the progress of the task can be tracked by those using a
screen reader.

>From an accessibility perspective, using the progress element isn't
simpler than the ARIA values. The min and max values, whether ARIA or
progress element, are statically assigned in the associated element,
and the current value is updated based on the progress of the element.
What does differ is that the progress element does have a visual
indicator that is automatically updated. Unfortunately, though, it's a
visual indicator we have no control over. What we see, is what we get.
It will differ based on operating system and user agent. We only have
minimal control over how the element can be styled.

Compare that to the options we have available in various libraries
today. There are sites that provide the ability to create our own
throbber (indeterminate progress)[8], as well as dozens if not
hundreds of existing images freely available on the web that we can
use. Annotate with a little ARIA, and we're set.

As for indeterminate, there are too many available libraries for this
functionality to list, but I wanted to specifically point out the
jQuery UI progress bars[9], as jQuery UI does have ARIA accessibility
built into the library. Dojo's widget library Dijit has promised
complete ARIA integration, and already made strides in that direction,
especially with the progress bar[10]. So has the YUI 2
ProgressBar[11], as well as other popular libraries.

A decade ago, when HTML4 was newly released, something like progress
would have been welcome. At that time, support for JavaScript and CSS
was limited, and accessibility support was non-existent. That was
years ago. Now, there are several progress bar options available that
are well designed, fast, efficient, accessible, and which we can use
as easily as we use CSS now. They are truly plug-and-play simple. Not
only do these libraries and plug-ins and packaged widgets provide the
progress element's functionality, they do a superior job, both from an
accessibility perspective, and the fact that they work now. They also
provide user options for styling and behavior far beyond what we could
ever have with the progress element, and how we style the progress bar
packaged widgets transcends both browser and operating system, to
provide a nicely consistent appearance and behavior.

Details

Based on the March 4th, 2010 draft, remove Section 4.10.16 and Section
10.4.13 and any references to either and to the progress element.

Impact

Positive Effects

Removes another new element in the rather large pool of new HTML5
elements. This reduces the burden on all user agents, including
browsers, editors, and so on. It's important for the HTML WG not to
introduce new elements that are redundant considering the state of
supporting technologies today, such as CSS for styling, JavaScript for
behavior, and ARIA for both semantics and accessibility (and even
Canvas and SVG, if we want to get fancy with graphics). We shouldn't
be creating single-purposed elements unless there is no existing
functionality that can serve the purpose of the element, and that's
definitely not true with progress bars.

Negative Effects

Will require some of the Editor's time to make the change. Since the
element has not been implemented in any browser or other user agent
(that I'm aware of), there should be no cost associated with having to
remove support for the element other than editing the specification.

References


[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552

[2] http://www.mozilla.org/access/dhtml/progressbar

[3] http://www.w3.org/TR/wai-aria/roles#progressbar

[4] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuenow

[5] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuemin

[6] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuemax

[7] http://www.w3.org/TR/wai-aria/states_and_properties#aria-valuetext

[8] http://www.ajaxload.info/

[9] http://docs.jquery.com/UI/Progressbar

[10] http://docs.dojocampus.org/dijit/ProgressBar

[11] http://developer.yahoo.com/yui/progressbar/

------------------------

Shelley Powers
http://realtech.burningbird.net

Received on Wednesday, 31 March 2010 13:40:53 UTC