Hi, How should the atk/AT-SPI states be used to indicate a widget is disabled/grayed? In gail, it looks like:
1) STATE_FOCUSABLE && (STATE_ENABLED || STATE_SENSITIVE) means the widget is interactive 2) STATE_FOCUSABLE && !(STATE_ENABLED || STATE_SENSITIVE) means the widget is not interactive because it is currently disabled 3) !STATE_FOCUSABLE means the widget is never interactive so it's neither enabled or disabled In Firefox 3.0, STATE_FOCUSABLE is removed when a widget is disabled/grayed. This makes the second case (currently disabled) and third case (can never be enabled or disabled) indistinguishable. This is problematic for an AT which wants to announce "disabled" when an interactive widget is currently not available for interaction, but say nothing when the widget can never become interactive. For instance, consider a grayed submit button on a web page versus a paragraph of text on the same page. According to the AT-SPI docs: "STATE_FOCUSABLE: Indicates this object can accept keyboard focus, which means all events resulting from typing on the keyboard will normally be passed to it when it has focus." When a control is in a disabled stated, it cannot accept the keyboard focus. Under this interpretation, it sounds like Firefox is doing the right thing. But then there is still a lack of distinction. Does anyone have an elegant solution or recommendation that doesn't involve having the AT revert to guessing which roles are interactive and which are not? Thanks, Pete _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
