Probably similar to progressmeter however HTML5 make difference between these controls. Should expose nsIAccessibleValue.

Mounir, are we exposing something for the low, high, and optimum attributes? Because there is currently no accessibility API to deal with these values. The rest looks vaguely similar to the progress element, indeed.

Firefox should expose the inner phrasing content of a meter element. I created a test case for that: http://hoffburg.at/bugreports/meter.html

more examples: http://peter.sh/examples/?/html/meter-progress.html Max, if it looks interesting please feel free to pick up this one.

(In reply to Marco Zehe (:MarcoZ) from comment #1) > Mounir, are we exposing something for the low, high, and optimum attributes? > Because there is currently no accessibility API to deal with these values. > The rest looks vaguely similar to the progress element, indeed. Color is changed from green to yellow when the value is out of low/high range. I'm curious what state the element has when its value is out of optimum range? As alternative we could expose low/high/optimum as object attributes.

The meter element is exposing the values of low/high/optimum: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-meter-element Regarding the states, there is NS_EVENT_STATE_OPTIMUM, NS_EVENT_STATE_SUB_OPTIMUM and NS_EVENT_STATE_SUB_SUB_OPTIMUM. You can find the logic in HTMLMeterElement::GetOptimumState().

Ideas how to expose optimum states into accessibility API?

Can you explain how optimum, sub-optimum and sub-sub-optimum are represented visually? I don't follow this. I think we're going to need new accessible states, but I was imagining low, optimum and high states based on my understanding of the spec. (Object attributes could be used, but I think they should probably be boolean for the current value, not numeric.)

(In reply to James Teh [:Jamie] from comment #7) > Can you explain how optimum, sub-optimum and sub-sub-optimum are represented > visually? I don't follow this. by default green, yellow and red colors, I believe people can CSS style them as they want > I think we're going to need new accessible states, but I was imagining low, > optimum and high states based on my understanding of the spec. (Object > attributes could be used, but I think they should probably be boolean for > the current value, not numeric.) yep, they are boolean, states sound like a right way

I thought of bug 687202 to increase the a11y of the meter element but I never finished the patch. Would that be worth it?

(In reply to Mounir Lamouri (:mounir) from comment #9) > I thought of bug 687202 to increase the a11y of the meter element but I > never finished the patch. Would that be worth it? sure, the bug seems to be a good step forward to improve a11y and usability. this bug is different, it's about how to expose the control through a11y APIs.

AKT part is done (https://bugzilla.gnome.org/show_bug.cgi?id=684576), we need to implement it. Curious, if Yurii wants to pick it up ;)

any update on this?

I have no new data on this.

fyi, ATK and IA2 both have ROLE_LEVEL_BAR now (we need to update their IDLs to pick up the changes)