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 17:01:04 UTC