W3C home > Mailing lists > Public > public-pfwg@w3.org > February 2015

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

From: Bryan Garaventa <bryan.garaventa@ssbbartgroup.com>
Date: Thu, 19 Feb 2015 21:53:26 +0000
To: "public-pfwg@w3.org" <public-pfwg@w3.org>
Message-ID: <BL2PR03MB33848E11C6D72AF29286D3D982D0@BL2PR03MB338.namprd03.prod.outlook.com>
I've been noticing that the use of aria-owns and what it's intended purpose is, and now what it appears to do, doesn't appear to match and is causing accessibility issues.

>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.

According to the spec, at
http://www.w3.org/TR/wai-aria/states_and_properties#aria-owns
This is supported on "all elements of the base markup".

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.

<html><body>

<input title="test" type="text" aria-owns="testDivId" />

<div id="testDivId">
Constraints:
<ul><li>
No special characters
</li><li>
Must be less than 20 characters in length
</li></ul>
</div>

</body></html>

The result of this, is that if you view this markup using JAWS16 in Win7 using Firefox, the content of the Div entirely disappears, and 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.

What JAWS is trying to do makes sense, because it is trying to remap the parent/child relationship accordingly. However it is trying to do so on an element that does not support child elements.

It makes more sense to specify in the spec that aria-owns will perform this parent/child remapping in the accessibility tree for elements that support child elements, and for elements that do not support the use of child elements, aria-controls should be used instead.

This is valid for constructs like ARIA Comboboxes, where it states for editable comboboxes at
http://www.w3.org/TR/wai-aria/roles#combobox
"Authors SHOULD associate the combobox textfield with its listbox using aria-owns."

Since the most reliable method for implementing an editable ARIA Combobox is to use a native Input field, this aria-owns association and parent/child remapping is causing accessibility issues.

I would suggest using aria-controls for this purpose instead, which actually does work reliably.
E.G
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20and%20Readonly)/demo.htm


Bryan Garaventa
Senior Accessibility Engineer
SSB BART Group, Inc.
bryan.garaventa@ssbbartgroup.com
415.624.2709 (o)
www.SSBBartGroup.com
Received on Thursday, 19 February 2015 21:53:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:45:23 UTC