Re: Top-10 Accessibility API Wish List
Re: Top-10 Accessibility API Wish List
- Subject: Re: Top-10 Accessibility API Wish List
- From: Guy Fullerton <email@hidden>
- Date: Wed, 11 Sep 2002 12:22:51 -0700
On 9/10/02 11:32 PM, "Michael Kamprath" <email@hidden> 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.
Making your priorities known is a great idea. However, this Top-10 list
should not be treated as a replacement for:
1) Filing bugs and feature requests. Our bug tracking system (and not the
Top-10 list in the mailing list archive) is ultimately what we base our task
prioritization on. The list is a cool excercize, but the items better be
backed up by actual bugs and feature requests if you want them fixed/added
:)
2) Talk to your Developer Relations rep to let them know which bugs/features
are most important to you, and why. (Because there are some Developer
Relations folks on this list, posting to this list sort of counts. However,
it certainly doesn't hurt to follow up with your rep directly.)
(I'm sure most of you already know this, but I'm just being pedantic in case
there are people on the list who don't know it.)
>
As of now, my top requests for the API are as follows:
>
>
1. Parity between Cocoa and Carbon window UI elements
You mention several specific differences. Please make sure each of these
(and any others you find) is accompanied by a bug.
>
This includes the ability to close a
>
window by "pressing" the window's close box UI element.
We already have a bug to cover this.
That said, we are still trying to figure out exactly how well we can
physically support it, as well as whether we even want to do so for certain
applications. CarbonEvent-based windows can be given this functionality
easily. Unfortunately, non-CarbonEvent-based windows must be "puppet
stringed" (read: "tricked") into thinking there was a mouse down in the
close box.
Though it is a solvable problem for most apps, "puppet stringing" is complex
and, well, rather gross. We're not convinced that we want to puppet string
non-CarbonEvent-based apps into having richer Accessibility support. In
addition, there will be some applications that simply don't respond to
puppet stringing.
>
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.
I'm not convinced this is truly necessary for Section 508 support. Why do
you want this?
Because you refer to your "utility," I am compelled to get up on a soapbox
for a few seconds:
The Accessibility APIs are intended for implementing Assistive Applications
that intend to provide support for Section 508. The API is not intended as a
mechanism to power general utility applications. Therefore, our current
policy is to prioritize Section 508 needs before the needs of utility
applications.
I'm not trying to pick on your app/needs specifically. The word "utility"
just triggered the response :)
>
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?
The intent is for windows with a proxy icon to support the AXProxy
attribute, which is a UIElement with role AXImage. I believe Cocoa supports
this in Jaguar. Carbon does not (yet).
_______________________________________________
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.