ISSUE-97 Change Proposal

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 Wednesday, 31 March 2010 13:45:13 UTC