Re: [g-a-devel] new states for meter element

[Piñeiro <apinheiro igalia com>]

Hi Alexander.

As alluded to in our response yesterday, we have a couple of issues (in
addition to the one you raised) related to AtkValue which need to be
resolved:

1. AT-SPI2 (and Orca) expect values as doubles; ATK, however, allows GValues
2. There is no way to get the on-screen description of the double value
(e.g. aria-valuetext)

In order to address the above, and also accommodate the new need
introduced by HTML5, we propose the following:

* atk_value_get_current_value_and_text
   This method would return current value and text representation (if
present; otherwise an empty string)
* atk_value_get_range
   This method would return the minimum and maximum values as dobules.
* atk_value_get_sub_ranges
    The return value of this method requires some input from you, but
tentatively it would return the sub range minimum as a double, sub range
maximum as a double, and some descriptor/label as a string.
      
Taking your green-yellow-red Firefox example, HTML5 is introducing
ranges which you are communicating visually via colors. Communicating
this information non-visually potentially requires screen readers to
know where each color (sub range) starts and stops as that is the only
way to convey "how good" or "how bad" the current value is. We assume
that providing the subrange values should not be a problem for
implementors. Our questions, for which we need your input, are:

1. Will there be a string to describe each subrange, such as good
(green), ok (yellow), and bad (red)?
2.  If so, where will that string come from?
3. Also, will that string be predictable (always "good", "ok", "bad") or
context-specific ("strong", "average", "weak")?

Piñeiro&Joanie


On 12/11/2013 07:28 PM, Piñeiro wrote:
> Hi Alexander,
>
> Thanks for pointing out this new element. We are right now at the
> WebkitGTK2013 hackfest, so Joanie and I had some time to discuss this.
> After giving this some thought, we think that a state is not the proper
> way to go. It would be better to expose this by expanding the AtkValue
> interface. It already exposes current, minimum and maximum. So the idea
> would be to expose low, high and optimum as well. On a related note, we
> are also currently discussing the addition of string description of
> numerical values to address the issues identified in bug684576 [1]. Soon
> we'll have an improved AtkValue interface for your consideration and
> implementation.
>
> Again, thanks for the ping
>
> BR
>
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=684576
>
>
> On 12/11/2013 06:15 PM, Alexander Surkov wrote:
> > Hi.
> >
> > HTML5 introduced meter element [1], which is basically a progressbar
> > role but can be in special states:
> >
> > 1) optimal state when value is in optimal rage  (for example, if  low
> > < optimum < high then value should be in [low, high], if optimum >
> > high then value should be greater than high.
> >
> > 2) suboptimal state when value is in range next to optimum range (for
> > example, if low < optimum < high then value < low is suboptimal.
> >
> > 3) subsuboptimal state when value is not neither optimal nor
> > suboptimal for example if optimum > high but value < low.
> >
> > Firefox colors these states as green/yellow/red.
> >
> > Would it be reasonable to introduce these states in ATK? Any other
> > ways to expose that info?
> >
> > [1]
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-meter-element
> >
> > Mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=559770
> > Some examples: http://peter.sh/examples/?/html/meter-progress.html
> > Try it out:
> > http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_meter
> >
> > Thanks.
> > Alex.

-- 
----
Alejandro Piñeiro