Re: When should kAXFocusedUIElementChangedNotification be sent?
Re: When should kAXFocusedUIElementChangedNotification be sent?
- Subject: Re: When should kAXFocusedUIElementChangedNotification be sent?
- From: Bill Cheeseman <email@hidden>
- Date: Mon, 12 Jun 2006 18:25:12 -0400
- Thread-topic: When should kAXFocusedUIElementChangedNotification be sent?
on 2006-06-12 3:19 PM, Tom Bunch at email@hidden wrote:
> My understanding is that kAXFocusedUIElementChangedNotification
> should be sent whenever the keyboard focus changes. That's kind of
> an imprecise way of describing the problem however, as we're not so
> much talking about whether an NSResponder acceptsFirstResponder as we
> are talking about whether the responder chain has changed. For
> example, if I open two Safari windows (I think any two WebViews will
> do) and make sure no NSResponder is selected in either, then click
> back and forth between them, kAXFocusedUIElementChangedNotification
> is not sent. Obviously, since spacebar will always scroll the
> foremost Safari window, the responder chain is changing, and hence I
> would argue that the notification should be sent. Now, it's easy
> enough to work around that by also looking for a
> kAXFocusedWindowChangedNotification - I just wanted to see if my
> understanding of the semantic of
> kAXFocusedUIElementChangedNotification was flawed somehow.
I wonder if "keyboard focus" for UI elements is defined in terms of
"printable" characters (text views, text fields), while "keyboard focus" for
windows is defined more broadly, in terms of navigation keys and function
keys.
If that is so, your example would be a situation where no UI element in the
application has keyboard focus, but there is nevertheless a window that has
keyboard focus in the sense that it is frontmost, or "key."
The documentation for AXNotificationConstants.h says this of
kAXFocusedUIElementChangedNotification: "Return Value: New focused UI
Element or Application UI Element if there's no focus." The second half of
that statement implies that kAXFocusedUIElementChangedNotification is
expected to be sent when a UI Element loses focus, as well as when a UI
Element gains focus. In the former case, the return value would be the
application element if no other UI Element gained focus at the same time.
Consistently with this, the Accessibility Reference for Assistive
Applications lists kAXFocusedUIElementAttribute as an attribute that is
"specific to the top-level UI Element representing an application."
In addition, the fact that there is a separate notification for key windows,
kAXFocusedWindowChangedNotification (and for main windows,
kAXMainWindowChangedNotification), implies to me that
kAXFocusedUIElementChangedNotification does not apply to changes of focus
among windows, on a principle of economy.
But logic and parsing the documentation are particularly unreliable in the
world of accessibility. The answer is more likely to depend on the
engineers' conception of what a person with vision disability would find
sensible and useful. From that perspective, I suppose that somebody typing
words wants to know if they are going to appear in a different text field,
never mind which window it's in, and whether the words aren't going to
appear at all because no UI element in the application has focus. When a
window with an active text field comes to the front, I suppose that both the
UI element notification and the window notification should be sent. If the
new front window has no active text field but the old front window did, then
both notifications would be sent and the UI element notification would
inform the typist that the application now has keyboard focus (meaning that
typed characters will appear nowhere). If neither window had an active text
field, then only the window notification would be sent, as you observed with
Safari -- because the application had keyboard focus for purposes of typing
no matter which window was frontmost, and so bringing the other window to
the front did not change keyboard focus for purposes of typing.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
PreFab Software - http://www.prefab.com/scripting.html
The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com
Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Accessibility-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden