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: John Louch <email@hidden>
- Date: Sun, 5 Oct 2003 11:36:33 -0700
On Oct 5, 2003, at 11:23 AM, David Niemeijer wrote:
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?
Yes, there is not way to do this in Jaguar or Panther.
> 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 can submit a radar request to make the focused uielement settable
in the Dock. Though I would want to see more context on why it is
needed.
> 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.
Ok paste this info into the bug you are going to write in the bug, and
I will look into it.
Thanks,
jl
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.
_______________________________________________
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.