(Once we have ATK_STATE_READ_ONLY, we'll need it in AT-SPI for ATs.)

+++ This bug was initially created as a clone of Bug #665598 +++

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