Re: [g-a-devel] Focus - AT vs. mouse/keyboard manipulation

[Bill Haneman <Bill Haneman Sun COM>]

(cross-posting to metacity-devel, because I don't know how to fix this
and I suspect the metacity hackers will)

Hi Zack;

I think you're encountering several issues here.  With regard to the
Action interface, items which aren't posted to the screen may still be
activated.  For menu items this probably isn't really a problem, with
respect to the desired effect for end users.

For dialogs, I agree that there's a problem.  The difficulty you are
seeing is probably a result of "focus stealing prevention" which was
added to the metacity window manager (in the gnome-2.14 timeframe I
think).  This behavioral change was intended to prevent applications
from "stealing" focus except in response to a direct user action. 
However, I believe that the AT-SPI Actions should probably be treated as
"user" actions even though they are technically 'programmatic' ones.  I
don't know whether new metacity or window-manager API would be required
to make this work, or not.  For this reason I am cross-posting your
message.

Metacity folks: if an end-user of an assistive technology such as a
screen reader or onscreen keyboard invokes the "activate" action on a
button which opens a dialog, the desired behavior is for that dialog to
take focus, since it is being posted in response to an end-user action
(albeit indirectly).  I am happy to annotate the AT-SPI docs to warn
clients of the API that they should not use the Action:doAction API
except in response to direct end-user requests.

Zack, a specific test case that we can use for diagnosis and discussion
would help.  Do you have one in mind?

Best regards,

Bill

On Wed, 2006-08-09 at 21:57, Zack Cerza wrote:
> Hi,
> 
> If I do something that results in a dialog popping up via either the 
> mouse or the keyboard, that dialog has focus. If I open the dialog via 
> AT-SPI's AccessibleAction interfaces (e.g. 'click' and/or 'activate'), 
> the dialog does not have focus. Now, it seems that this would be 
> considered a bug, but even if it isn't, I can't seem to find an 
> alternative way to ensure that the dialog is given focus.
> 
> I did try using AccessibleComponent_grabFocus() on Accessibles which 
> implement that interface, but ran into problems; for the vast majority 
> of AccessibleComponents, the function returns FALSE, indicating that it 
> was unsuccessful (which it was). Why would that function always fail?
> 
> I did find that most (if not all) Accessibles with an 
> AccessibleEditableText interface can successfully grabFocus, but even 
> then, the window or dialog they're in must be focused; they will not 
> grab focus from another window.
> 
> So, my question is: How can an AT ensure that the same windows and UI 
> controls that have focus after a given user action (i.e. with just the 
> keyboard and/or mouse) is performed have focus when the same workflow is 
> performed by the AT?
> 
> Thanks,
> Zack
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel