At this moment the default implementation of ref_state_set is adding some states. As the summary says, some of them are ATK_STATE_SELECTABLE/ATK_STATE_SELECTED:

 * For any object checks if the parent is an ATK_SELECTION. This interface is implemented by objects like lists.
 * If it is an ATK_SELECTION it add the state ATK_STATE_SELECTABLE *always*
 * Additionally it asks through the atk_selection interface which is the element selected in order to add ATK_STATE_SELECTED if applies

So the implementation assumes that if an object is a list, their children will be always selectable. But this is not always the case. In some cases you could have a list of items enabled, with some of the items enabled and the others not. If some of the list items are not enabled, obviously, you can't select it. One example here [1]. And I really doubt that you couldn't do the same with others.

So I see two options:
a) Remove that code from AtkObject. Assume that at the AtkObject level you can't know a so specific thing, and that should be decided by the specific subclass. This has the problem that although some of the current toolkit implementations are already managing the SELECTABLE/SELECTED thing, some not, so just removing the code could lead to several regressions.

b) Add a new method on atk_selection. In the same way that we have this:
    gboolean atk_selection_is_child_selected (AtkSelection selection, gint i);
Add this one:
    gboolean atk_selection_is_child_selectable (AtkSelection selection, gint i);
So on AtkObject they would use that method to decide if add that state or not. One option to avoid the initial regressions until that method is implemented by all the toolkits would be add a default implementation where child_selectable==TRUE. In the case of [1], they would only need to reimplement atk_selection_is_child_selectable.


Right now I'm not sure whats the best option. b) is less intrusive and regression-prone. a) seems more natural, as AtkObject are supposed to be a abstract/general class, so managing state sets seems somewhat out of scope at that level.

[1] https://bugs.webkit.org/show_bug.cgi?id=98376#c3