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

The definition of ATSPI_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 ATSPI_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 ATSPI_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 ATSPI state would be
preferable.

For this reason, I am proposing the creation of ATSPI_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
ATSPI_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