Alexander Surkov | 7 Mar 2012 07:45
Picon

ATK STATE_EDITABLE

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.

Thank you.
Alex
Piñeiro | 7 Mar 2012 15:40
Favicon

Re: ATK STATE_EDITABLE

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.

(Continue reading)

Alexander Surkov | 7 Mar 2012 17:23
Picon

Re: ATK STATE_EDITABLE

> 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 <at> 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.
(Continue reading)


Gmane