Summary: Remove the progress element.
In the bug associated with this issue, 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.
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 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”, with associated ARIA states, aria-valuenow, aria-valuemin, aria-valuemax, and the optional aria-valuetext, 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), 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, 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. So has the YUI 2 ProgressBar, as well as other popular libraries.
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.
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.