Re: ISSUE-97 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:44 AM, Shelley Powers wrote:

> Summary
>
>    Summary: Remove the meter element.
>
> Rationale
>
> The rationale given by the HTML5 editor[1] for keeping the meter  
> element is:
>
>    "Rationale: We have to have <meter> if we have <progress> because  
> otherwise
>    people will abuse <progress> to get gauges, leading to bad  
> accessibility."
>
> It's difficult to write a change proposal asking to remove the meter
> element, because there's so little justification for keeping it. That
> we need to have a meter element because people supposedly will use the
> progress element incorrectly means we either have not defined the
> progress element well enough, or we're trying to prevent people from
> using what seems to them to be the natural element to use.
>
> The problem associated with the HTML5 meter element is that it is
> almost identical to the progress element: a long flat rectangle that
> has a minimum and maximum value and a current value, with the bar
> filled in up to that current value. However, if you search online on
> the term "gauge widget" almost all cases reflect a circular gauge, not
> a progress bar-like object.
>
> Most gauge widgets online are also created from various libraries and
> toolkits, such as Google's Visualization API[2], the Dojo Toolkit
> Analog Gauge[3], or the Dojo Bar Gauge[4], which does have a bar-like
> image. All have a more sophisticated interface that what we could
> expect from a built-in HTML5 widget. In fact, the HTML5 built-in gauge
> could be created using one div nested in another, with a different
> color of background, and with a sized width equal to the gauge
> percentage.
>
> As for the semantics and accessibility of the widget, I would imagine
> that the ARIA role of "progressbar"[5] and associated state values
> indicating the low and high values, and the current value, could be as
> usable for this type of bar gauge, as they would be for a progress
> bar. After all, the way to tell this type of bar gauge from a progress
> bar is the context of the use. In fact, the text description of the
> gauge that's recommended for the HTML5 meter element would also work
> for any of the gauge libraries.
>
> Regardless, if the current ARIA progressbar role is not appropriate,
> or the text description is not sufficient, it's better to work with
> the WAI-ARIA folks to derive the appropriate role and states, because
> a gauge such as the HTML5 meter specification is no different than a
> gauge that can be created in something like SVG, or other graphical
> environment. The need for accessibility in a gauge does not end with
> just HTML.
>
> Details
>
> Based on the March 4th version of the HTML5 specification, remove
> Section 4.10.17 and Section 10.4.12, and any references to these
> sections and the meter element.
>
> Impact
>
> Positive
>
> Removing meter removes another element from the fairly large number of
> elements and attributes added with HTML5. In addition, it removes an
> element whose sole purpose and seemingly sole use case, is to ensure
> that another element was not used incorrectly. This, to me, is not a
> strong case for adding an element to HTML5, especially considering how
> much work each new element generates for browsers, HTML editors, and
> so on.
>
> In addition, not creating a new element encourages people to use any
> number of the existing libraries and packaged widgets already
> available for use, and that have been available for use for many
> years. The meter element welds structure, behavior, and style into a
> single purposed element. Such single purposed elements are counter to
> the direction the web has been going for the last decade. Especially
> now, when we have so many new graphical possibilities, with the new
> support for SVG inline in HTML, and increased support for the Canvas
> element. It's better to encourage people to use existing graphical
> technologies such as CSS, SVG, and Canvas, and existing semantics and
> accessibility technologies, such as ARIA, RDFa, Microformats, and
> Microdata, and leave the structure to HTML.
>
> Negative
>
> This change will require some of the editor's time.
>
> References
>
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=8555
>
> [2] http://code.google.com/apis/visualization/documentation/gallery/gauge.html
>
> [3] http://archive.dojotoolkit.org/nightly/dojotoolkit/dojox/widget/tests/test_AnalogGaugeWidget.html
>
> [4] http://docs.dojocampus.org/dojox/widget/BarGauge
>
> [5] http://www.w3.org/TR/wai-aria/roles#progressbar
>
> ----
>
> Shelley Powers
> http://realtech.burningbird.net
>

Received on Tuesday, 6 April 2010 20:21:43 UTC