GNOME Bugzilla – Bug 665598
Add ATK_STATE_READ_ONLY
Last modified: 2014-12-04 17:19:19 UTC
The definition of ATK_STATE_EDITABLE is: "Indicates the user can change the contents of this object." This clearly addresses text widgets. However, whether or not it also applies to widgets which: * are enabled * are sensitive * are focusable * have a usually-changeable state * presently lack the ability to change the state Consider, for example, cb4 on this page [1]. The checkbox is for all intents and purposes a normal checkbox, however the user is prevented from changing its state. If we agree that 'state' != 'contents', then ATK_STATE_EDITABLE (or the lack thereof) would not be a means to communicate the present read-only condition of this checkbox (and other widgets like it). In this case, a new ATK state would be needed. If, on the other hand, the conclusion is that 'state' == 'contents', then every widget whose contents (including state) could be altered by the user would need to have ATK_STATE_EDITABLE added to it. This would involve quite a few widgets and multiple toolkits: quite a lot of work given how rare things like the read-only dojo checkbox happen to be. Therefore, a new ATK state would be preferable. For this reason, I am proposing the creation of ATK_STATE_READ_ONLY. The addition of this state would raise the question of what to do about read-only text widgets. Should STATE_EDITABLE be removed and ATK_STATE_READ_ONLY be added? Or something else? I personally think this is less of a concern. But FWIW, we could deprecate STATE_EDITABLE and make the new read-only state apply to all widgets. [1] http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_CheckBox.html
(In reply to comment #0) > The definition of ATK_STATE_EDITABLE is: "Indicates the user can change the > contents of this object." This clearly addresses text widgets. However, whether > or not it also applies to widgets which: > > * are enabled > * are sensitive > * are focusable > * have a usually-changeable state > * presently lack the ability to change the state > > Consider, for example, cb4 on this page [1]. The checkbox is for all intents > and purposes a normal checkbox, however the user is prevented from changing its > state. > > If we agree that 'state' != 'contents', then ATK_STATE_EDITABLE (or the lack > thereof) would not be a means to communicate the present read-only condition of > this checkbox (and other widgets like it). > In this case, a new ATK state would > be needed. Well, why not? In this case we have a checkbox. On his state_set it shouldn't include ATK_STATE_EDITABLE. But it would include ATK_STATE_CHECKED. > In this case, a new ATK state would > be needed. Why? What's the difference here between having a ATK_STATE_READ_ONLY and not having ATK_STATE_EDITABLE. > If, on the other hand, the conclusion is that 'state' == 'contents', then every > widget whose contents (including state) could be altered by the user would need > to have ATK_STATE_EDITABLE added to it. AFAIK, this is what is happening right now in most ATK implementations. Why is this a problem now? > This would involve quite a few widgets > and multiple toolkits: quite a lot of work given how rare things like the > read-only dojo checkbox happen to be. Therefore, a new ATK state would be > preferable. Is this read-only dojo checkbox a rare thing? What do you mean? Could you elaborate it?
> Well, why not? In this case we have a checkbox. On his state_set it shouldn't > include ATK_STATE_EDITABLE. But it would include ATK_STATE_CHECKED. Assuming it is checked. ;) But that's not really relevant here IMHO. Let's say the user moves to it with Tab. It has state checked. The screen reader says "foo checkbox checked." So far so good. Now the user presses Space to toggle the state. The state is not going to be toggled. The screen reader is not going to say anything in response to the lack of event. This is puzzling for the user who expected the state to get toggled like it normally does. In such an instance (assuming reasonable interface design) there is hopefully going to be *something* somewhere near the widget which gives a sighted user a hint as to why you cannot just click on the silly checkbox to toggle its state. For the user who is blind, "looking around" often means moving away from the thing you wish to look. This is inefficient at best. If we have an ATK_STATE_READ_ONLY, the screen reader could instead say the following in response to the focus event: "foo read only checkbox checked" (or a variant thereof). Confusion, frustration, and need to move focus away from the widget to try to figure out why its state did not change: eliminated. ATK_STATE_EDITABLE (when removed) accomplishes this for text widgets. Normally we expect textviews, entries, password text fields, etc. to be editable. When they lack this state and are given focus, Orca tells the user the thing is "read only." However, toolkits in my experience only add/remove ATK_STATE_EDITABLE for things which are truly editable (text widgets where you can change the contents); not for widgets whose state you can (or cannot) change. > > In this case, a new ATK state would > > be needed. > > Why? What's the difference here between having a ATK_STATE_READ_ONLY and not > having ATK_STATE_EDITABLE. See above. > > If, on the other hand, the conclusion is that 'state' == 'contents', then every > > widget whose contents (including state) could be altered by the user would need > > to have ATK_STATE_EDITABLE added to it. > > AFAIK, this is what is happening right now in most ATK implementations. Why is > this a problem now? (In my experience) widgets whose state cannot be altered are made insensitive (are "greyed out"). So... It's not so much that this is a problem now as it is the fact that I found this widget which was sensitive and enabled and focusable, but whose state cannot be toggled. I was about to file a bug to get the implementor of the widget to expose this detail to ATs and realized that we do not have an appropriate state for the implementor to use. Having said all that, if more interface designers conclude that read-only checkboxes (and other such widgets) are preferable to making them insensitive, we will start to have a problem (imho). > > This would involve quite a few widgets > > and multiple toolkits: quite a lot of work given how rare things like the > > read-only dojo checkbox happen to be. Therefore, a new ATK state would be > > preferable. > > Is this read-only dojo checkbox a rare thing? What do you mean? Could you > elaborate it? It's the first such beast I've seen. Will it be the last?
(In reply to comment #2) > If we have an ATK_STATE_READ_ONLY, the screen reader could instead say the > following in response to the focus event: "foo read only checkbox checked" (or > a variant thereof). Confusion, frustration, and need to move focus away from > the widget to try to figure out why its state did not change: eliminated. Taking into account that we found several practical use cases where this state could be useful (more right now at WebkitGTK 2012 hackfest), I'm ok with adding this state. The only thing that we need to be careful is about the documentation, of both ATK_STATE_READ_ONLY and ATK_STATE_EDITABLE to not lead to confusion. Should I find a time slot to add this state or just wait for coming patches?
Created attachment 231194 [details] [review] Patch to add the new state (This doesn't do anything regarding ATK_STATE_EDITABLE as it's not yet clear to me what its fate will be.)
Ping?
(In reply to comment #5) > Ping? Hi. Well, as you say about your patch ... (In reply to comment #4) > Created an attachment (id=231194) [details] [review] > Patch to add the new state > > (This doesn't do anything regarding ATK_STATE_EDITABLE as it's not yet clear to > me what its fate will be.) But I'm still concerned about having both, ATK_STATE_EDITABLE (in fact the lack of) and ATK_STATE_READ_ONLY, and not being clearly documented when use one or the other (or if you can combine both). So, could you take another round of thinking to check if it is possible to have a clear documentation about both states?
Created attachment 292104 [details] [review] Proposed patch (In reply to comment #6) > (In reply to comment #5) > > Ping? > > Hi. Well, as you say about your patch ... (In reply to comment #4) > > > Created an attachment (id=231194) [details] [review] [details] [review] > > Patch to add the new state > > > > (This doesn't do anything regarding ATK_STATE_EDITABLE as it's not yet clear to > > me what its fate will be.) > > But I'm still concerned about having both, ATK_STATE_EDITABLE (in fact the lack > of) and ATK_STATE_READ_ONLY, and not being clearly documented when use one or > the other (or if you can combine both). > > So, could you take another round of thinking to check if it is possible to have > a clear documentation about both states? Done. Please review. Thanks!
Review of attachment 292104 [details] [review]: LGTM
Comment on attachment 292104 [details] [review] Proposed patch https://git.gnome.org/browse/atk/commit/?id=c338c7b99 (I'll do patches for AT-SPI2 later today.)