Re: aria-owns

CCed public-pfwg-comments

On Mar 25, 2008, at 15:15, Aaron M Leventhal wrote:
> Henri Sivonen <> wrote on 03/25/2008 07:33:39 AM:
> > Hi,
> >
> > On Mar 24, 2008, at 23:13, Aaron M Leventhal wrote:
> > > I read a discussion about aria-owns on #whatwg the other day.
> > >
> > > Just to clarify, aria-owns is less strong than a parent - child
> > > relationship. It doesn't change the parent child relationship.
> >
> > As I understood the spec, it does change the parent-child  
> relationship
> > as far as role containment rules are concerned, right? For example,
> > ARIA says that the parent of a role=treeitem must be a role=tree.  
> With
> > even the possibility that some element may have an aria-owns
> > attribute, the parent might be anywhere in the document and software
> > has to cover that case. That a pretty big chunk of collateral  
> general
> > complexity as a consequence of addressing three specific use cases.
> I ned to go through the spec again, but if it says it changes parent- 
> child, that's wrong.

The spec says: "Defines an object as a parent of another document  
element, when the child does not appear directly in the subtree of the  

I read that as arbitrary reparenting when reflecting the DOM in the  
accessible tree. I think my reading is reasonable considering that  
aria-owns is defined to be a global property and considering what the  
"best practices" doc says:

> It would be too hard to implement, with circular reference  
> possibilities etc. What a nightmare that would be!

I agreed.

> I expressed that it doesn't work that way at our last f2f so  
> everyone is aware of that.

The spec should say how exactly it is supposed to work. :-)

> It actually works how I expressed, where "owns" really means  
> something less strong than parentness. I would have suggested they  
> call it "attaches" but "owns" was better at expressing the direction.

In that case, even if the name stays, it would make sense to figure  
out what exactly are the cases where aria-owns is needed and that  
browser implementors think make sense to support and then define aria- 
owns for those cases only instead of defining it as a global property.

> >
> > > ATs pick it up through "accessible relations".
> > >
> > > Owns assumes that real DOM children are generally rendered inside
> > > the parent -- parents are containers.
> > > However, aria-owns is for conceptual relations that are visually
> > > related.
> > >
> > > Here are 3 use cases:
> > > - Submenus -- a menu item owns the submenu. The real children of  
> the
> > > menu item are its text and image contents. Using aria-owns allows
> > > the web author to use CSS positioning for the submenu.
> >
> > Why aren't submenus contained in the supermenu in the DOM?  
> JavaScript
> > menus are often implemented as <ul> hierarchies where the submenus  
> are
> > indeed subtrees even if CSS is used to move the submenu aside is the
> > layout box tree.
> Submenus aren't contained in the supermenu in the DOM in many cases  
> because "that's really hard and web authors don't do it that way". I  
> tried to force proper parenting on everyone from the start, but it  
> was rejected by authors using ARIA. One of the strengths of ARIA is  
> that you can retrofit inaccessible apps with a11y without rewriting  
> everything. Also I'm not sure but it may have been an issue of just  
> getting the damn thing to work in IE.

:-( Isn't proper nesting the easy way to do it? Where are the submenus  
rooted in the DOM otherwise?

> >
> > > - Tree row children. The real children of the tree row are the
> > > contents of the row. The user thinks of the children as sub-rows  
> --
> > > but they're really a different kind of child. We called it  
> ownership.
> >
> > It seems to me that using something like aria-level or a role=row-
> > specific IDREF relation in this case would be much less disruptive
> > than a global aria-owns.
> You have 3 options for trees:
> 1. A DOM structure where role="group" brings items of the same level  
> together. The previous sibling of the group is the containing item.  
> This is how the old XUL trees (before the outliner API) used to  
> work. Example:

I think it's worth pointing out that when groups aren't themselves  
nested, you could use <tbody> for the higher level structure and <tr>  
for the substructure (in which case the first <tr> in a <tbody> would  
be on the outer level and subsequent <tr>s its subrows).

> 2. You can use aria-level as well.  This is especially important for  
> trees where only the currently visible items have been loaded in the  
> DOM. For trees of thousands of items that's important for performa  
> nce.
> 3. aria-owns. I don't remember why we thought that aria-owns was a  
> necessary option for authors.

Given the potential complexity of aria-owns, it probably shouldn't be  
an option without a strong use case that aria-level wouldn't cover.  
Also, if aria-owns is kept for treegrid rows, I think the spec should  
clearly define the document conformance requirements and UA  
conformance requirements in such a way that they are just narrow  
enough to permit addressing the use case.

> > > - Diagrams. Take for example an organizational chart. Each
> > > "employee" object may have contents that show the employee, their
> > > name and other info. However, a conceptual tree is shown. That  
> tree
> > > can be connected with aria-owns.
> >
> > It seems to me that this use case should be addressed with a  
> diagram-
> > specific relationship that doesn't affect the containment rules of  
> all
> > of ARIA.
> >
> > > It's also less markup to put aria-owns on the owner node instead  
> of
> > > on each child. It might be more difficult for the tool writers,  
> but
> > > then there are a lot fewer of us than authors. That's why I think
> > > putting it on the owner node is better.
> >
> > What happens when authors make cycles with aria-owns?
> That's an issue with any relation -- aria-labelledby, aria-controls,  
> etc.

If node A is labelledby node B which is labelledby node C, should B or  
C be read as the label for A? Intuitively and per spec, B. That is,  
the spec doesn't specify labelledby to be traversed recursively. So  
cycles don't seem to be an immediate problem for labelledby.

The spec doesn't say what UAs are supposed to do with aria-controls,  
so I can't assess whether cycles are a problem.

However, when a relation does cause a problem when used cyclically,  
the spec needs to say what UAs are to do in that case.

> > Are the
> > accessible children of a node ordered?
> aria-owns does *not* affect children. We need to fix the spec.
> > If yes, how do the actual DOM
> > children and the aria-owns children interleave?
> aria-owns is just a relation, it's not first-class in the sense it  
> has no effect on children.
> > (If no, aria-ownedby
> > would work and would require less updating by an author-provided
> > script when a node is added or removed dynamically, as there  
> wouldn't
> > be a need for the script to rebuild a list of siblings but a pointer
> > to the parent would suffice.) Or are the actual DOM children totally
> > overridden by aria-owns?
> >
> > I would like to send these comments to public-pfwg-comments. May I
> > forward this message there with the parts you wrote intact?
> Sure.


Henri Sivonen

Received on Tuesday, 25 March 2008 14:41:30 UTC