This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8421 - Resolve issue of aria-owns implementation in MSAA and UAI
Summary: Resolve issue of aria-owns implementation in MSAA and UAI
Status: RESOLVED DUPLICATE of bug 7101
Alias: None
Product: ARIA
Classification: Unclassified
Component: Core AAM (show other bugs)
Version: 1.0
Hardware: PC Windows XP
: P1 major
Target Milestone: ---
Assignee: David Bolter
QA Contact: ARIA UA Implementors
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-12-02 14:36 UTC by Andi Snow-Weaver
Modified: 2010-01-19 15:49 UTC (History)
1 user (show)

See Also:


Attachments

Description Andi Snow-Weaver 2009-12-02 14:36:09 UTC
In the state and property mapping table, for aria-owns, MSAA and UIA currently say "the structure should be reflected in the accessible tree as directed by aria-owns." 

David proposes removing but this came from Microsoft.
Comment 1 David Bolter 2009-12-02 15:07:33 UTC
ARIA owns should not change the structure of the accessible tree exposed through platform API. The accessible tree should be based on the real DOM tree; while the aria owns can describe addition parent child relations that should be exposed via IA2/ATK relations for example, or some other mechanism that doesn't require tree restructure.

Tree restructure would be a nightmare, could lead to cyclic graphs and other nasties, and was never the intent of aria-owns.
Comment 2 Andi Snow-Weaver 2009-12-08 16:20:34 UTC
Per Cynthia, IE has implemented aria-owns this way. Will have to address this before Last Call.
Comment 3 Andi Snow-Weaver 2009-12-08 16:29:04 UTC
Logging some info from e-mails on this:

From Rich:

Correct. It is up to the AT to handle the relationship. It is not up the user agent to merge it with the tree. That would result in a nightmare for browser manufacturers as Apple found out. 

The other question I am wresting with is do we really need it? Dojo never used it and I am waiting to hear back from Todd Kloots on YUI. 

Aaron responds:

There are a few use cases at least.

1. Tree grids -- shows relationship between rows (the children of a row are what's contained in it -- the cells)
2. Content in an element that is moved around with CSS as the app finds necessary, to be attached to other elements. This is easier and more performant than deleting and recreating the content, and aria-owns can fix up the reading order. Could be done with aria-flowto possibly.
3. Diagrams, like org charts.
4. Submenus, aria-owns shows where the menu parent is

Rich responds: 

Aaron I understand. SAP and the Dojo community hae built 1 and 4 but I have not seen it used. Also, Apple has an aria-flowto API mapping.

Nobody, to date, has built a diagram using ARIA that I am aware of yet but it will come.

Aaron responds:

Rich, I suppose the tree grid doesn't need aria-owns because it uses aria-level?

It might be possible to remove aria-owns and use flowto for most cases, and in the tree grid case you'd have to use aria-level to express logical parenthood, because the grid cells are already the children of the rows.

Rich responds: 

Yes, that was my line of thinking. The fact that Dojo did not need aria-owns was one proof point. I was waiting to hear back from Todd Kloots on YUI. 

What I am thinking is that we could move aria-owns to ARIA 2.0 when we need to investigate diagrams, etc. in more detail. That said, we do have canvas to deal with today in HTML 5. Admittedly, I am on the fence about this. I'd like to hear other people's thoughts.
Comment 4 David Bolter 2010-01-19 15:49:51 UTC

*** This bug has been marked as a duplicate of bug 7101 ***