User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0 Build Identifier: We should have default colors to represent the differents states of this element (optimal, sub-optimal and sub-sub-optimal) Reproducible: Always

Like bug 644361, we want a correct default style for the meter element but the meter element isn't going to have a native style on GTK and maybe not on Windows so we are going to need something nice enough to be seen by most users. I believe we should use hex colors and probably keep the same background color than the progress element and just have three different colors (green, orange, red) corresponding to the three states of the element. Basically, that means removing the background-color property from "::-moz-meter-bar" rule and add three new rules: :-moz-meter-optimum::-moz-meter-bar { background-color: green; } :-moz-meter-sub-optimum::-moz-meter-bar { background-color: orange; } :-moz-meter-sub-sub-optimum::-moz-meter-bar { background-color: red; }

Yoan, Vincent and Laurent, make sure to ask a review to David Bolter who is in charge of the accessibility for Mozilla: we want to be sure that the colors are not going to be hard to distinguish for visually impaired users.

Comment on attachment 538084 [details] [diff] [review] Patch v1.0 Review of attachment 538084 [details] [diff] [review]: -----------------------------------------------------------------

The default style here seems way more critic than with the progress element because there is no meter widget in GTK and Windows XP. We might be able to do one for Windows Vista and 7 but that would be a hack. Webkit does use gradiants and the default style for the meter element is very close to the MacOS X native style. I don't know what Opera does but it's clearly not a simple background. Though, I don't really like using a gradiant because it might not be really intuitive to disable for authors (and a pain because you have to disable -{webkit,moz,o,}-gradiants). I just want to be sure that everyone is ok with that.

Comment on attachment 538086 [details] [diff] [review] Tests v1.1 Review of attachment 538086 [details] [diff] [review]: ----------------------------------------------------------------- Instead of "colors", could you name the new directory "defaul-style". In addition, you have to add "include default-style/reftest.list" in meter/reftest.list. Except that and the nit below, nice tests :) ::: layout/reftests/forms/meter/style.css @@ +27,5 @@ > + /* #00ae00 is green. */ > + background-color: #00ae00; > +} > + > +meter::-moz-meter-bar { ::-moz-meter-bar would be enough here. Though, it's for a test and it's correct so you don't really have to worry.

(In reply to comment #10) > Webkit does use gradiants and the default style for the meter element is > very close to the MacOS X native style. I don't know what Opera does but > it's clearly not a simple background. Though, I don't really like using a > gradiant because it might not be really intuitive to disable for authors > (and a pain because you have to disable -{webkit,moz,o,}-gradiants). I just > want to be sure that everyone is ok with that. You don't disable gradients, since gradients aren't a property; you just set background:none, surely? That should be fine.

Comment on attachment 538084 [details] [diff] [review] Patch v1.0 This seems fine, but to serve all our users we should never just use only color to convey information. I need to know how the meter element is used in this context. Will it normally also have some other visual indication of state, like a needle on a dial?

(In reply to comment #14) > Comment on attachment 538084 [details] [diff] [review] [review] > Patch v1.0 > > This seems fine, but to serve all our users we should never just use only > color to convey information. I need to know how the meter element is used in > this context. Will it normally also have some other visual indication of > state, like a needle on a dial? The meter element has two information: the value that is represented by the bar (like a progress bar) and the value "state" which can be optimum, sub-optimum or sub-sub-optimum and this is represented by a pseudo-class, thus, a color. There is no other indication of this state for the moment. Except exposing it trough the a11y API, I don't see any way to make it clearer: if a user can't distinguish the three colors, it might be hard to find something (the element is quite small). I will probably update the patch to use gradiants tomorrow.

Comment on attachment 538084 [details] [diff] [review] Patch v1.0 Modulo the choice of colors and whatnot, this seems ok (though in general those selectors would be bad; the saving grace is that they're for a particular pseudo-element).

Chrome non-native rendering is, IMO, too close to the MacOS X native rendering and, in case of you wonder, it's not Mac-specific: with GTK, Chromium has the same rendering. Though, it is way better than what Opera does and what we could do with plain colors. So, I think we should use gradients given that as said Roc, setting the background property disables the gradient (but not background-color unfortunately). However, I'm wondering if we should use something similar to Webkit/Chrome or try to make it less MacOS-like (by adding a border, for example). In one hand, I feel bad to make <meter> looks too close to what MacOS X does but in the other hand, it might be stupid to make it uglier just to not make it look likes MacOS X (even more given that GTK and Windows don't have a specific widget for that). I don't think I'm the best person to solve this issue. Does someone know who I should talk with to solve it?

Steve, do we already have thinking on what the browser can do to ensure good meter element accessibility? Obviously using color-only to convey information is problematic, but here we also have position.

(In reply to comment #21) > Steve, do we already have thinking on what the browser can do to ensure good > meter element accessibility? Obviously using color-only to convey > information is problematic, but here we also have position. If i am reading the spec [1] and the coments above correctly (big if) the plan is to use color alone to signify the different states of "optimum". If so then there are issues in regards to using color alone to convey information [2]. Unless there is some other *visible* means other than color that will differentiate the optimum levels. I have created an example of the issue for color blind users [3] [1] http://dev.w3.org/html5/spec/the-button-element.html#attr-meter-optimum [2]http://www.w3.org/WAI/WCAG20/quickref/#qr-visual-audio-contrast-without-color [3] http://www.html5accessibility.com/tests/progress.html

The optimum level could be marked as a groove perpendicular to the meter itself to avoid relying on color alone.

(In reply to comment #23) > The optimum level could be marked as a groove perpendicular to the meter > itself to avoid relying on color alone. The usefulness and accessibility of meter would also be improved by providing methods to indicate units and type. take the example from spec: <p>The grapefruit pie had a radius of 12cm and a height of 2cm.</p> <dl> <dt>Radius: <dd> <meter min=0 max=20 value=12>12cm</meter> <dt>Height: <dd> <meter min=0 max=10 value=2>2cm</meter> </dl> If you view it in a browser that supports meter it provides ambiguous information as it is not clear what the units are or what the values are. It is unambiguous when meter is not supported. Alternatively the text content of the meter element could be displayed by default above/below the meter.

(In reply to comment #23) > The optimum level could be marked as a groove perpendicular to the meter > itself to avoid relying on color alone. I like this idea.

(In reply to comment #22) Thanks for this assessment Steve. I think given this assessment and possibly with Henri's idea we can fix this bug. (In reply to comment #24) Regarding the placement of text, we'll tackle how we handle the various examples of this on a separate bug.

(In reply to comment #25) > (In reply to comment #23) > > The optimum level could be marked as a groove perpendicular to the meter > > itself to avoid relying on color alone. > > I like this idea. potential issue is that if optimum is not specified the optimum will be half way [1], how are users going to distnguish it from a simple indication of half way? [1]http://dev.w3.org/html5/spec/the-button-element.html#attr-meter-optimum

(In reply to comment #27) > (In reply to comment #25) > > (In reply to comment #23) > > > The optimum level could be marked as a groove perpendicular to the meter > > > itself to avoid relying on color alone. > > > > I like this idea. > > potential issue is that if optimum is not specified the optimum will be half > way [1], how are users going to distnguish it from a simple indication of > half way? You mean that we should make the indication clear enough to be able to see the bar and the indication when they are at the same place? You could probably put two small arrows to point the optimal value? (or only one...) I'm wondering if we should use that indication for native widgets? Should we assume that native widgets are already accessible or should we make them less native and more accessible by adding that?

I think native widget accessibility is owned by the native platform. I think tampering with trying to superimpose accessibility can be problematic, especially since we don't control updates to native widget a11y.

Mounir are you blocked on me?

After thinking of different solutions, I think the best solution would be to indicate the low and high values instead of the optimum one. The idea is that the optimum value might be a wrong indicator especially when the optimum isn't explicitly set. Having a tick mark (like a small arrow) to point the low and high value will show the users there are some delimiters. With the context, it should be easy to understand if the value has to be higher than the high marker, lower or in the middle. David, what do you think of this?

https://hg.mozilla.org/mozilla-central/rev/02e39a1af642 https://hg.mozilla.org/mozilla-central/rev/0e06a2f6af3a