Parents & children not consistent
Parents & children not consistent
- Subject: Parents & children not consistent
- From: Bill Cheeseman <email@hidden>
- Date: Sat, 09 Nov 2002 08:57:10 -0500
I notice that the parent branch of a UIElement (its ancestors) can include
UIElements that are omitted from the application's children branches (its
descendants). In other words, if you walk backwards from a UIElement to its
root by traversing its parents, you may encounter some UIElements that you
won't see when you return along the same branch by traversing its children.
The one case of this that I have found is a ruler in a scroll area that
contains a text area. If I run Apple's new UIElement Inspector and hold the
mouse over a ruler in a text view -- in TextEdit, for example -- the ruler
is shown as an "AXUnknown" UIElement, with the scroll area as its immediate
parent. The code that does this uses the AXParent attribute. But if I use my
own Accessibility Browser to examine the children tree from the root
UIElement down to its leafs, using the AXChildren attribute, I never see the
ruler or any other "AXUnknown" UIElement.
Conceptually, it seems to me that if a ruler can have a parent, it must be
the parent's child.
Is this discrepancy a bug in the accessiblity API? Or was it a deliberate
decision based on the difficulty of including something like the ruler in
the children attribute?
In the case of a ruler, it occurs to me that it would be pretty easy to
include it in the children attribute of the scroll area. You would have to
check whether the starting element is a scroll area and, if so, check
whether it contains a text area among its children and, if so, use the
AXUIElementCopyElementAtPosition function, passing in a point guaranteed to
be where a ruler would be located if a ruler were present in the scroll area
(taking into account that there can be vertical and horizontal rulers).
Are there any other UIElements that behave the way a text ruler does? If so,
each might have to be special-cased in a similar fashion. Or maybe you could
develop a generalized algorithm that collects the rects of all the "regions"
owned by the root UIElement, then see whether any UIElement whose role is
"AXUnknown" is located at any point within the collected rects. I suppose
this would be pretty slow, so maybe that has something to do with why it
hasn't been implemented.
This discrepancy won't have much of an effect on most assistive
applications, I suppose, because screen readers will see the ruler the same
way the UIElement Inspector does, by checking under the mouse. But some
assistive applications might want to inform a user whether a window has a
ruler without regard to the mouse location -- as my Accessibility Browser
wants to.
I guess it would be best if the accessibility API knew about rulers and
such, instead of calling them unknown. Is this a Cocoa vs. Carbon issue? Is
it generally an issue for UI objects that are implemented in Cocoa but not
in Carbon, or vice versa?
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
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.