GNOME Bugzilla – Bug 672368
Add STATE_CHECKABLE
Last modified: 2013-12-11 13:11:56 UTC
We have: * STATE_FOCUSABLE and STATE_FOCUSED * STATE_EXPANDABLE and STATE_EXPANDED * STATE_CHECKED So we don't have a reliable means to present a toggle-able, but presently unchecked widget as "unchecked" to users. Note: Orca currently treats checkboxes, radio buttons, and the equivalent menu items as toggle-able. But anything else which could be checked, but is not presently checked, is hard to recognize.
Well, I talked a little about this <state>ed and <stated>able thing on a recent thread: https://mail.gnome.org/archives/gnome-accessibility-devel/2012-March/msg00005.html In general, in ATK we have the states, but they only provide info if they are added. If an object has a state we know that is in that state, and also that he can be in that state. But if an object lack and state, we don't know if potentially it can have that state. Generally, this "potential" thing are related to roles. So a TOGGLE_BUTTON (and others) has the potential to have the state CHECKED. But this is not documented at all, so the apps use them using common sense (as mentioned on comment 0, about what Orca does). But it is also true that in spite of the role, at a given moment this "potential" is not true. A button is in general focusable, but in some cases it can be dimmed (although this is related to ENABLED). ATK tried to solve this on the more evident cases. FOCUSABLE and EXPANDABLE were mentioned, but we also have SELEC[ED/ABLE]. But I would like to avoid to start to add two states per each use case. Ideally it would be good to have a solution that would allow us to know if an object has the potential to be in one state, and to know if it is in the state or not. On the previous link I mention some options, but I'm not sure about any of them, so that would require more thought. Anyway, this seems a middle-long term solution, but this patch ask for something now. Is that state really required right now? Can we wait until thinking a little more how to do this stuff "in the right thing"? If not we can just add that "CHECKABLE" state now. Note: while reviewing current states I realized that we also had the opposite, "-ABLE" states without his "-ED". ie: ATK_STATE_MULTISELECTABLE. This for example, is an state obviously related to AtkSelection. Note2: I also detected some states that doesn't fit on this "-ABLE"/"-ED". Like HORIZONTAL and VERTICAL. Anyway, for me this is something that shouldn't be expressed with states. An AtkOrientation on AtkComponent would be better, IMHO.
(In reply to comment #1) > Generally, this "potential" thing are related to roles. So a TOGGLE_BUTTON (and > others) has the potential to have the state CHECKED. But this is not documented > at all, so the apps use them using common sense (as mentioned on comment 0, > about what Orca does). Yeah, and usually that works, but not always. In particular, take a look at GtkListStore demo in gtk3-demo. Those are all accessible table cells (which I think makes sense), but only the first column is toggle-able. > Anyway, this seems a middle-long term solution, but this patch ask for > something now. I'm sorry. This isn't a "now" thing. I suppose I should have blocked the ATK 3 bug. Benjamin solved the "now" problem by re-adding the 'toggle' action within Gtk+ 3. He just wasn't happy about it. ;) And I mentioned that if we had something like STATE_CHECKABLE, we would need that 'toggle' action. And he asked in response if we had such a bug already filed. And... well... Oops, we didn't. So.... Here it is. :) I just want a reliable solution that we all can live with. Be it this state or something else. > Is that state really required right now? Can we wait until > thinking a little more how to do this stuff "in the right thing"? Yup, we can wait. > Note: while reviewing current states I realized that we also had the opposite, > "-ABLE" states without his "-ED". ie: ATK_STATE_MULTISELECTABLE. But that case may be a tad different -- or not problematic. Knowing something can have multiple selections is nice. Identifying that something presently has multiple selections is something we can find out via the selection interface. Thus, an 'ed' state is not needed.
s/would need/wouldn't need/
*** This bug has been marked as a duplicate of bug 712576 ***