Re: ISSUE-96 Change Proposal

Thanks for providing a Change Proposal for this issue! The chairs  are  
reviewing Change Proposals to ensure that they meet the required  
structure. Here is our feedback on this Change Proposal (actually the  
version subsequently uploaded to the wiki):

(1) This Change Proposal includes all of the required sections with  
appropriate content. The Rationale and Details sections seem sufficient.

We believe this Change Proposal is well-formed and ready for  
consideration by the Working Group.

Regards,
Maciej

On Mar 31, 2010, at 6:40 AM, Shelley Powers wrote:

> 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 Tuesday, 6 April 2010 20:22:04 UTC