RE: Clarification in the spec regarding proper usage of aria-owns and what it actually does?

Thanks, the explanation does help a lot.

I think there actually is great value in being able to rearrange the accessibility tree, since this is a powerful feature and would make it possible to construct cohesive widgets that comprise differing DOM node containers, such as ARIA grids, trees, amongst others where the DOM structure may not be nested properly, and this would need to occur in order for these changes to be reflected by ATs that use virtual offscreen models.

This would also be valuable in cases when dynamically inserted content isn't rendered inline with triggering elements, making it possible to add aria-owns on the parent container to make this content appear in an accessible location for ATs that support virtual offscreen models as well. 

It would be a powerful feature if used appropriately, where there is none if this functionality doesn't exist.

It would just need to have some logic to distinguish which elements should not have this built in, such as certain form fields and images for example, to prevent weird side effects.

-----Original Message-----
From: Joseph Scheuhammer [mailto:clown@alum.mit.edu] 
Sent: Friday, February 20, 2015 9:01 AM
To: Bryan Garaventa; public-pfwg@w3.org
Subject: Re: Clarification in the spec regarding proper usage of aria-owns and what it actually does?

Hi Bryan,

Comments inline.
>  From what I understand, the purpose of aria-owns is to rearrange the accessibility tree for ATs so that previously unassociated elements can be remapped as parent/child element relationships to provide an understandable structure where before there was none.

It's more accurate to say that the purpose of aria-owns is to declare parent/child relationships that cannot be made using the DOM.  Whether that actually results in a different accessibility tree is an implementation detail.  Currently FF does not rearrange the tree, although they are considering changing that.

In terms of AAPI mappings for aria-owns, UIA does rearrange the tree.  
IA2 and ATK/AT-SPI do not; rather they use child-of and parent-of relationship pointers.  AXAPI uses an array AXLinkedUIElements that contains pointers to the owned accessibles [1].

> Now, the problem I'm seeing, is that this concept doesn't work on elements that don't support child elements.
>
> Here is a simple example of this. ...

I loaded your example file into FF 35.0.1, and used the DOM inspector.  
The a11y tree is not rearranged.  The accessible with ROLE_ENTRY has a RELATION_NODE_PARENT_OF pointer to an acccessible with ROLE_SECTION.  
The ROLE_SECTION has a RELATION_NODE_CHILD_OF pointer to the ROLE_ENTRY.  In short, FF is consistent with what the core-aam says.  I have no idea why "... the content of the Div entirely disappears" using JAWS.  I can arrow to that content using Orca and it speaks it.

> The result of this, is that if you view this markup using JAWS16 ... in IE11, the content of the Div appears to be placed within the edit field almost as though it is part of the value itself.
>

IE11 is using the UIA mappings, so it is rearranging the a11y tree such that the div is a child branch of the input (or so I assume -- I didn't actually inspect it).  I don't know enough about UIA and whether control type Edit accessibles can have children.

But, what you are seeing might be argument against rearranging the tree.

P.S.  I also loaded your example into Safari and used their inspector tool.  The implementation differs somewhat from what is documented in the core-aam.  They do not rearrange the a11y tree, and the AXLinkedUIElements array property of the AXTextField accessible is empty.  But, there is an AXOwns array that contains a pointer to the AXGroup accessible that corresponds to the div.

[1] http://rawgit.com/w3c/aria/master/core-aam/core-aam.html#ariaOwns

--
;;;;joseph.

'Array(16).join("wat" - 1) + " Batman!"'
            - G. Bernhardt -

Received on Friday, 20 February 2015 20:28:27 UTC