Re: Determining whether a window supports accessibility
Re: Determining whether a window supports accessibility
- Subject: Re: Determining whether a window supports accessibility
- From: David Niemeijer <email@hidden>
- Date: Thu, 2 Jun 2005 19:47:47 +0200
At 9:07 -0700 2/6/05, Mike Engber wrote:
In a sense, what you're asking is "How can I discover if a window
contains UIElements that aren't exposed via the Accessibility APIs?"
Clearly, this cannot be answered by Accessibility APIs.
I think that is indeed a good rephrase of my question, but I guess
even a user pane or custom control would be partially exposed, so
direct drawing into a window by-passing the control mamager is
probably what leads to areas of the window being reported as AXWindow
even though a user sees static or editable text there (as in the Word
case).
As someone already pointed out, you can take a guess by asking the
window for its children. If there are none (apart the standard
window controls), that's pretty suspicious. On the other hand it
could just be an empty window. There is no way to tell for sure just
using the Accessibility APIs.
Makes sense, my question was probably mainly wishful thinking.
If you don't limit yourself to the Accessibility APIs, then there
are other possibilities for detecting the problem. E.g. if the app
supports AppleScript you could see if what AppleScript has to say
about the window matches what the Accessibility APIs report. Note,
AppleScript GUI scripting is built on top of the Accessibility APIs,
so using that won't accomplish anything.
Good point. Sounds like it will become a process of investigating app
by app to make sure what the situation is.
Thanks for your quick response,
david.
_______________________________________________
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