Re: How to move focus to the Dock using the Accessibility API?
Re: How to move focus to the Dock using the Accessibility API?
- Subject: Re: How to move focus to the Dock using the Accessibility API?
- From: David Niemeijer <email@hidden>
- Date: Sun, 5 Oct 2003 20:23:42 +0200
Hi John,
Thanks for your quick replies (fast weekend service is always even
more appreciated!). Please find my replies and explanations below.
> As part of an assistive application I need to programmatically focus
the Dock so that I can tab through it. I know full-keyboard access
allows focussing of the Dock, but for various reasons I cannot rely
on that and need to get the Dock focussed progammatically. Is there a
way, once I have the Dock's process ID and/or AXUIElementRef to make
the Dock obtain keyboard focus?
There is no way to do this. You cannot rely on the keyboard system keyboard
navigation because the keys can change, get turned off, etc.
Exactly, that is why I was looking for a solution that does not rely
on Full Keyboard Access to be turned on, or on specific key
combinations. When you say "no way" I am assuming you are referring
to both Jaguar and Panther, right?
> I would like to know whether it is somehow possible to use the
Accessibility API to highlight something, such as a menu item or a
button in the Dock without actually pressing or picking it (which
obviously will do more than just highlighting)?
The dock does not support accessorizing its menus.
I don't want to access the Dock's menus. I guess I phrased that
badly. I was referring to the highlighting that takes place in
(menubar) menus when you move over them with the mouse down (or with
the tab key), not to the dock menus. The Dock also has highlighting
for its buttons when you tab through them using full keyboard access,
that was intended as another example of user interface elements that
support a form of highlighting that I would like to be able to
trigger through the Accessibility API.
> You are absolutely right. One of the funny things about the dock is
that is does not have windows, only buttons, while of course for a
user it looks like buttons in a window. I have also tried making the
dock's process the front but that did not seem to do the trick either.
Never try to set a background process to the front. It can break that
process.
Thanks for the warning. I was just desperate to figure out how to get
focus to the Dock. Next time I will first think about whether a
process is background only.
The real question is why do you need to tab through the Dock. You can of
course get the children of the Dock, and then "pretend" to tab through it in
your UI. The only action you can do with the dock is press on the item, so
you are still pretty limited.
The real answer is that Mac OS X presents a graphical user interface
so users (without visual impairments) want to access it whenever
possible through the graphical user-interface rather than through
some kind of substitute I can create within my own windows (using the
Accessibility API to collect the information). In July we released a
barebones version of SwitchXS, which provides practically full access
to Mac OS X for people who can only use one or more switches to
access their computer. I say barebones because it provides full mouse
and keyboard emulation but requires people to access the menus or
dock using either SwitchXS' mouse emulation or Full Keyboard Access
through SwitchXS' keyboard emulation. This is far from convenient for
many switch users who would rather be able to scan through the actual
user interface elements. Of course I could make a series of dynamic
buttons in my own window that would list, for instance, the current
dock buttons or allow a user to navigate the menu structure, but that
is not what users are asking me. They want to scan through the actual
menus and the actual dock, just like their keyboard and mouse using
brethren. Using the Accessibility API I access all the relevant
information to scan through menus and dock, but I also need to have
the graphical user interface reflect the current scan position by
proper highlighting. Working with a partially transparent colored
overlay window is not what users really want for interface elements
such as menu which they know have their own native highlighting. For
the dock that would not even work if it is hidden. It needs to get
focus to become visible in that case.
I am sure the Accessibility API gets used for some strange things now
and then, but in this case there is a real demand from disabled users
behind what I am trying to do. It just seems I need slightly more
control than what the current API gives me. I need to be able to
focus the dock just as I can already focus the menu bar and I would
ideally like to be able to highlight menu or dock elements as I scan
through them without having to rely on tabbing. Anyway, I will be
happy to write up some bug reports/feature requests. I just wanted to
check here whether what I want to do is not possible or whether I
just did not know how to do it.
Thanks,
david.
_______________________________________________
accessibility-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/accessibility-dev
Do not post admin requests to the list. They will be ignored.