From HTML WG Wiki
< ChangeProposals
Revision as of 00:17, 19 May 2010 by Grosmai (Talk | contribs)

Jump to: navigation, search

Issue 96 remove progress element


Remove the progress element.


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.


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.


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.

Conformance Classes Changes