Re: [g-a-devel] ATK STATE_EDITABLE

[Piñeiro <apinheiro igalia com>]

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