Hey Alexander, all.
On 12/13/2013 07:41 PM, Alexander Surkov wrote:
> Said above can be applied to wrong value which is exposed as invalid
> state but nevertheless it's a state. So I don't see a semantical
> contradiction here. If the value is optimal then control is in optimal
> state.
On this one I think we're going to have to agree to disagree. :)
> 2. A given value falls somewhere within a subrange. Something can be
> "a tiny bit {low,high}", "smackdab in the middle of {low,high}" or
> "really, really {low,high}. If we make these things AtkStates, we
> lose the "how much" with respect to those attributes.
>
>
> Right. Not sure how missing information bites though.
Well that depends on how these meters get represented "in the wild." On
a related note, we are also starting to see this type of widget show up
in GUI toolkits now (e.g. to represent password strength when creating a
new user account).
*If* there is a visual means to distinguish "kinda good" from "almost,
but not quite, optimal," then ATs should be able to convey this
information non-visually. Visual means to convey this seem reasonably
likely:
* Watching as the red bar moves closer and closer to the yellow area as
the user types more and varied characters into the password-definition
field.
* Shading: red -> dark orange -> medium orange -> light orange -> yellow
> is that ATK requirement?
Yes, as per the following ATK documentation [1]:
The "state-change" signal is emitted when an object's state changes
ATs expect to be notified when the state changes; not when the
implementor thinks the AT should be notified. But perhaps more
importantly, the following strikes me as problematic:
> It seems like AT would need value change event
> only (state change events would be duping in that case).
If you convey how optimal something is via state, and you do not emit
state-change events, how is an AT supposed to know that the new value
has an associated new state which should be presented to the user? The
AT would have to store the widget's state each time the value changed so
that it could do a comparison for a potential future value-change event.
In a perfect world, ATs would have a means by which to get details about
the subranges (and their associated optimality) AND be notified whenever
that optimality changes. In other words, we'd have all the
AtkValue-related API we proposed so that Orca's "Where Am I?" command
could describe how optimal the current value is, and we'd also have some
other signal to notify Orca that the optimality has just changed so that
Orca could pass along this notification to the user. But that seems like
pushing our luck by asking "too much" of implementors. (If I'm wrong and
you're happy to also implement both, please let us know.)
Given a proper accessibility implementation, Orca has no need to store
the previous state of a widget. The same cannot be said for the previous
value: Orca needs to be able to filter out insignificant value changes
so as not to be constantly spewing out tons of speech and braille when a
value-expressing widget updates itself (which in some cases happens
extremely frequently). Since Orca is already storing the previous value,
it would not be much extra work for Orca to check if the new value has
an associated new optimality that the previous value lacked -- assuming
Orca can get the subranges via the accessible value interface.
> Also, what would the human-consumable name of these "states" be?
>
>
> a good question, probably OPTIMAL, SUBOPTIMAL and NOT_OPTIMAL or
> SUBSUBOPTIMAL if it makes sense.
That's gonna make for a fun translator note. ;)
Regardless of whether or not we go the state route (which continues to
not be my preference), or the subrange route, I think we're going to
need user-friendly descriptors with which to present the optimality. Not
sure what they should be, but I think "suboptimal" versus "not
optimal"/"sub-sub-optimal" is not a sufficiently clear distinction (in
addition to not being especially user friendly). What about:
* Bad, Better, Best
* Bad, Good, Optimal
* <something like the above here>
Once we figure out those descriptors, I can get them into Orca so that
they will be translated in time for the 3.12 release.
Thanks and take care.
--joanie
[1]
https://developer.gnome.org/atk/stable/AtkObject.html#AtkObject-state-change
_______________________________________________
gnome-accessibility-devel mailing list
gnome-accessibility-devel@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
