Re: [g-a-devel] ATK STATE_EDITABLE

[Alexander Surkov <surkov alexander gmail com>]

> I think that make sense maintaining that state to expose that "would
> be", as mentioned on the bug. ATK_STATE_EDITABLE + ATK_STATE_DISABLED
> would mean that you can't edit it now (as is disabled) but that
> potentially this is editable.

Cool. What's the usual process that's needed to be done before the the
idea gets into the spec? (Btw, latest IA2 spec allows editable state
on readonly textboxes).

The idea to keep states as methods looks appeal. Other great win is
this is performant way since the server doesn't need to calculate
states all together when AT doesn't need them. I assume the cost of
the server's method call is quite low on ATK so if AT needs to get
several states then it can call several methods unlike the case of out
of process calls on Windows.

Anyway it sounds interesting. I'd like to follow this progress.

Thank you.
Alex.


On Wed, Mar 7, 2012 at 11:40 PM, Piñeiro <apinheiro igalia com> wrote:
> On 03/07/2012 07:45 AM, Alexander Surkov wrote:
>> Hi. There's interesting discussion about editable vs unavailable state
>> happening at Mozilla bug -
>> https://bugzilla.mozilla.org/show_bug.cgi?id=733382. I put here some
>> summary of it.
>>
>> The ATK spec says: "Indicates the user can change the contents of this
>> object" - http://www.pygtk.org/docs/pygtk/atk-constants.html#atk-state-type-constants.
>> That means readonly and disabled text controls shouldn't be exposed as
>> editable. ATs might be interested to know whether the object is
>> potentially editable to put it into navigation order. Also that makes
>> it similar to other 'able' states like expandable or multiselectable
>> except focusable state which is sort of opposite to absent enabled
>> state. So let's consider an exampe:
>>
>> <p contentEditable="true" aria-disabled="true">
>>
>> Currently: no enabled state, no editable state. This paragraph exposed
>> absolutely identically to plain <p>.
>> Proposed: no enabled state, editable state is presented. AT understand
>> this paragraph is sort of control and can be used for typing when
>> enabled.
>>
>> Please let me know what you think.
>
> I think that make sense maintaining that state to expose that "would
> be", as mentioned on the bug. ATK_STATE_EDITABLE + ATK_STATE_DISABLED
> would mean that you can't edit it now (as is disabled) but that
> potentially this is editable.
>
> Now thinking on the middle-long term, in general this is a problem of
> how states are exposed, and also mentioned by Benjamin. We now when an
> object has a state, but we lack the info of what states an object could
> have. Ie: you mentioned ATK_STATE_CHECKED, but we lack
> ATK_STATE_CHECKABLE. So if an object is checked, we now that it is
> checkable, but if not, we can suppose that based on the role (ie:
> ATK_ROLE_CHECK_ITEM), but the fact is that this is not documented. In
> fact, in some case we have both, as we have ATK_STATE_FOCUSABLE and
> ATK_STATE_FOCUS.
>
> For example, on MacOS they explicitly put which attributes (that it is
> something like a mixture of states and other information) are related
> with each role. So in the case of Button [1], it need to have the
> attribute Focused, and so on.
>
> So this is something that we need to take into account for the future. I
> think that Benjamin proposed to move the states to be just properties
> tied to specific interfaces. But that would require to increase the
> amount of interfaces, probably as many as Roles, and would make this
> less dynamic. Other option is just document which states we expect from
> each role, although I'm not sure if document this could be enough, or if
> this is valid in each implementation. Other option could upgrading the
> state to more that just the specific enum, but enum and value. So for
> FOCUSABLE, we would have just one state, FOCUSABLE, and a value exposing
> if it is focused or not. As I think that this could apply for any state.
> But not sure if this is an overkill.
>
> BR
>
> [1]
> https://developer.apple.com/library/mac/#documentation/UserExperience/Reference/Accessibility_RoleAttribute_Ref/Role.html#//apple_ref/doc/uid/TP40007870-Roles-SW1
>
>
> --
> Alejandro Piñeiro Iglesias
>
> _______________________________________________
> gnome-accessibility-devel mailing list
> gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel