Hi, Joanie. I'm fine to go with any reasonable approach, anything that
helps you to expose widget features. If that's value interface then let's
do it. If states then I'm fine with it and agree to follow expected routine
like fire state change events. If we talk about state constants naming then
optimal/suboptimal/etc should be ok. If we talk about states announcement
then I agree that suboptimal is rather technical term and might be not
friendly to the majority but after all it seems to be a screen reader's
choice.
Alex.
On Mon, Dec 16, 2013 at 6:30 AM, Joanmarie Diggs <jdi...@igalia.com> wrote:
> 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
