Re: Top-10 Accessibility API Wish List
Re: Top-10 Accessibility API Wish List
- Subject: Re: Top-10 Accessibility API Wish List
- From: Andrew Taylor <email@hidden>
- Date: Wed, 11 Sep 2002 08:49:15 -0400
At 11:32 PM -0700 9/10/02, Michael Kamprath wrote:
I'm sure we have all submitted bug/feature requests to Apple concerning the
young Accessibility API's inability to do one task or the other. I thought
maybe it'd be a good idea for people on this mail list discuss what we want
out of the API in order to help (read: prod) Apple into implementing what we
need to make the API useful.
As of now, my top requests for the API are as follows:
1. Parity between Cocoa and Carbon window UI elements - right now, you can
not set a Carbon application's AXMainWindow attribute, or most any other
attribute, that you can in Cocoa application windows. This should be doable
as the Dock itself and the Jaguar command-~ window cycler are able to select
windows from Carbon applications. Since most major OS X applications are
written in Carbon, not Cocoa, no enabling Accessibility's API in Carbon
applications is a major deficiency. This includes the ability to close a
window by "pressing" the window's close box UI element.
2. Being able to determine the z-order and class of windows - My utility is
only interested in windows that are document windows, and it would be great
to be able to determine which window is behind the main window.
3. Be able to get a kAXProxyAttribute UI element's icon - under the WWDC
build of Jaguar, a proxy UI element used to have kAXFilenameAttribute
property, which was a complete system path to the file the proxy represents.
From that, you could get the proxy icon. Of course, this didn't work if the
proxy icon was not based on the file. However, it doesn't work at all
anymore under 6c115. Why? How can I discover the icon of a proxy UI element?
Does anybody else have anymore? I'd be happy to compile a list to present to
Apple (if the right recipients aren't already on this mail list).
We maintain information regarding the contents of windows until the
window is actually closed. Typically this is dictated text and the
supporting audio and speech recognition information.
When a window is hidden, instead of issuing a window hiddent event, a
kAXUIElementDestroyedNotification is issued, causing us to throw away
all our data structures in the expectation that the window is gone.
If the window is subsequently shown again, all dictation information
is not available. We don't need to access the window while it is
hidden.
_______________________________________________
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.