ARIA owns is for things where there are children, but they are not contained by the parent. This is necessary to separate 2 types of parent concept: 1. Parent as a container with children inside (like a groupbox or a document) -- this is the normal use of parent in an accessible object hierarchy 2. Parent as something which logically groups external items, as in a parent tree item, a menu item with a submenu, a button with a popup, or a diagram object with children, such as in an organizational chart. This is the concept of ARIA owns.
I'm not sure that ARIA really differentiates between the popup and non-popup case of owns. Owns doesn't care if the owned items are currently visible. Child of sounds right, but then the inverse relation isn't there. - Aaron David Bolter wrote: > Aaron Leventhal wrote: > >> We need to support the owns=[idrefs] relation, as well as hasparent=[idref]. >> They are basically the same, but owns allows you do create the >> definition on the owner vs. hasparent on what's owned. >> Owns can have more than 1 item, hasparent can contain only 1 ID. It's >> probable that hasparent will be removed before ARIA becomes final. >> >> Which ever is used, the user agent can expose both sides of the >> relationship via AT-SPI and IA2. >> >> We need to figure out which AT-SPI relations we should use for each. >> Here are the possibilities: >> >> RELATION_MEMBER_OF >> RELATION_NODE_CHILD_OF >> RELATION_SUBWINDOW_OF >> RELATION_EMBEDS >> RELATION_EMBEDDED_BY >> RELATION_POPUP_FOR >> RELATION_PARENT_WINDOW_OF >> >> Definitions of owns and haspopup here: >> http://www.w3.org/WAI/PF/Group/adaptable/ >> >> > > I don't have a login for this. But I did find this definition of the > owns relation: 'The owns property defines an object as a parent of > another document element, however the child does not appear directly in > the subtree of the owner." > (http://www.w3.org/TR/aria-state/) > > This definition makes is sound like an ancestor-of kind of relation but > I'd like clarity here. Is there an implied containment? Or an implied > "within subtree" (if you know what I mean)? > > Here is my attempt at a deductive approach based on this interpretation > of "owns" and having re-read the at-spi docs (and after a couple of > glasses of wine): > > RELATION_MEMBER_OF > * I don't understand the at-spi defintion of this relation clearly. > RELATION_NODE_CHILD_OF > * possibly > RELATION_SUBWINDOW_OF > * possibly but i don't like that it has "window" in the name... could > be confusing > RELATION_EMBEDS > * cross process definition doesn't fit. > RELATION_EMBEDDED_BY > * ditto > RELATION_POPUP_FOR > * popup is a subtype of "owns" correct? if so this doesn't seem to > capture all of "owns" > RELATION_PARENT_WINDOW_OF > * ditto comment to subwindow_of relation > > So I'd lean towards child_of but there is no reciprocal parent_of? > > What about RELATION_EXTENDED? > > Let's hear from the guru... Bill? > > D > > >> Definitions of AT-SPI relations here: >> http://www.gnome.org/~billh/at-spi-idl/html/namespaceAccessibility.html#a215 >> >> >> Opinions? >> >> - Aaron >> _______________________________________________ >> Gnome-accessibility-devel mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >> >> > > _______________________________________________ > Gnome-accessibility-devel mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
