Request for Clarification on aria-owns Usage in ARIA 1.2 Specification

[LaurenceRLewis]

Describe your concern

I would like to request clarification regarding the aria-owns property as described in the ARIA 1.2 Specification, specifically within the Characteristics table under the "Used in Roles" row, which states the value as "All elements of the base markup."

Upon reviewing the specification, I encountered two primary concerns:

• Definition Ambiguity: The term "All elements of the base markup" is not explicitly defined within the specification that I could find. This absence of a clear definition raises questions about the scope and limitations of applying the aria-owns property, especially regarding what constitutes "base markup" in various contexts.
• Application on HTML Elements: aria-owns is not permitted on certain HTML elements (e.g., img, input) that do not support child elements, yet it can be applied to their corresponding ARIA roles (e.g., role="img", role="textbox" on a div). This distinction suggests that the allowance of aria-owns is based on the capability of an element (or its assigned role) to have children, rather than the element type itself. This understanding, however, might not be immediately apparent to developers, potentially leading to misuse or confusion regarding the application of aria-owns on HTML elements and their ARIA role equivalents.

Given these points, I seek clarification on the following:

• Does the phrase "Allowed on roles 'All elements of the base markup'" refer exclusively to ARIA roles applied within a webpage, and not to the native HTML elements themselves?
• Could the specification benefit from additional detail or examples to clearly delineate the appropriate use cases for aria-owns, thereby preventing potential misinterpretation that it is applicable to all HTML elements by virtue of their ARIA role equivalents?
• The goal of this inquiry is to ensure the ARIA specification provides clear, unambiguous guidance to developers on the correct use of aria-owns. Any clarification or additional guidance that could be provided in the specification would be greatly appreciated.

Link to the version of the specification or documentation you were looking at at.

• Link to documentation: aria-owns property

Does the issue exists in the editors draft (the editors draft is the most recent draft of the specification)?

• Yes

[pkra]

Does the phrase "Allowed on roles 'All elements of the base markup'" refer exclusively to ARIA roles applied within a webpage, and not to the native HTML elements themselves?

From a quick look, git blame tells me this line (and others like it) were last changed 9 years ago so I think this is simply outdated language. I suspect we want to update the language to something like "All roles".

aria-owns is not permitted on certain HTML elements (e.g., img, input) that do not support child elements,

I do not see any restriction for aria-owns in the html-aria spec. Could you point to a reference?

This distinction suggests that the allowance of aria-owns is based on the capability of an element (or its assigned role) to have children, rather than the element type itself.

Do you happen to have a test that is exhibiting a problem? E.g., image and textbox roles require name-from-author. I don't immediately see how modifying the accessibility tree via aria-owns would matter here.

[LaurenceRLewis]

@pkra

I do not see any restriction for aria-owns in the html-aria spec. Could you point to a reference?

The HTML Living Standard and ARIA in HTML do not specify restrictions on aria-owns for elements like img and input, which cannot have child elements. This omission leads to confusion among developers and auditors, which I have seen in conducting accessibility audits. The response from developers when this is pointed out is always "it does not say that in the spec".

This is the reason I propose adding clarifications to the ARIA specifications. These should explicitly outline the use cases and limitations of aria-owns, especially for elements that cannot host children. Clear guidance will align development practices with accessibility standards. Let the ARIA documentation take the lead, just because it is not mentioned in other specifications and standards is not a reason not to address this gap.

Do you happen to have a test that is exhibiting a problem? E.g., image and textbox roles require name-from-author. I don't immediately see how modifying the accessibility tree via aria-owns would matter here.

The following Codepen example demonstrates that for input and role textbox the aria-owns is ignored in the accessibility tree when tested in both NVDA and JAWS in Chrome and Firefox. I included a valid use case example of an HTML list that is exposed in the accessibility tree. The accessibility tree is already providing the correct behaviour for aria-owns. It is the documentation that does not align to the behaviour.

• Working example: aria-owns should not be permitted on INPUT in the base markup

JAWS output from the Codepen example

The list is nested in HTML input and ARIA role textbox. This is not rendered in the accessibility tree.

• HTML Input test for ARIA-OWNS Edit - Type in text
• ARIA Input test for ARIA-OWNS edit - Type in text.

However, the aria-owns is rendered in the accessibility tree as a nested list.

list of 5 items • List item 1b • List item 2b list of 5 items nesting level 1 • List item 1c • List item 2c • List item 3c • List item 4c • List item 5c list end nesting level 1 • List item 3b • List item 4b • List item 5b list end

Incorrect implementation of aria-owns, stemming from gaps in guidelines, negatively affects screen reader user experience. This is the reason I suggest a review and update of the ARIA specifications to include clear instructions on aria-owns.

Research references

• Working example: Codepen aria-owns should not be permitted on INPUT in the base markup
• Rules of ARIA attribute usage by HTML element
• Accessible Rich Internet Applications (WAI-ARIA) 1.2 - aria-owns property
• The aria-owns attribute is used within the ARIA Combobox 1.0 design patterns which does not take into account support discrepancies with aria-owns that leads to critical accessibility issues in some browser and AT combinations. #978
• Revise allowed aria-* attributes for HTML comboboxes and listbox #384

[pkra]

Thanks for the codepen example.

The accessibility tree is already providing the correct behaviour for aria-owns.

Personally, I feel like it isn't but I agree with you that the spec needs to clarify things.

To explain: from my reading of the specs, I'd have expected the accessibility tree to make the lists children of the inputs - and thus largely ignored because a label is provided; the result would leave the actual lists fairly inaccessible. But user agents seem to agree on how they treat this situation: aria-owns appears to be ignored and the lists left where they are. I suspect the spec(s) should reflect this kind of agreement.

[scottaohara]

related https://github.com/w3c/html-aria/issues/385