Combobox: aria-controls or owns should be on input, not on combobox element, and only when combobox is expanded

[kbae00]

The spec has aria-controls as required on the combobox role, but the sample code immediately below that has the attribute on the input instead. Either way, the attribute can only exist there with the combobox expanded, since you can't point to elements out of the accessibility tree.

[carmacleod]

May be worth considering Heydon's article on aria-controls. :)

[mcking65]

@kbae00 commented:

The spec has aria-controls as required on the combobox role, but the sample code immediately below that has the attribute on the input instead.

The spec for ARIA 1.1 combobox says:

When a combobox is expanded, authors MUST ensure it contains or owns an element that has a role of listbox, tree, grid, or dialog. This element is the combobox popup. When the combobox is expanded, authors MUST set aria-controls on the textbox element to a value that refers to the combobox popup element.

So, for the 1.1 pattern, aria-controls goes on the textbox as shown in the sample code.

@kbae00 commented:

Either way, the attribute can only exist there with the combobox expanded, since you can't point to elements out of the accessibility tree.

The spec says to include it when the combobox is expanded. However, in core-AAM section 5.6.3.2 Reverse Relations it says:

All WAI-ARIA references must point to an element that is exposed as an accessible object in the accessibility tree. When the referenced object is not exposed in the accessibility tree (e.g. because it is hidden), the reference is null.

A null reference is equivalent to not specifying the property. So, when browsers are working correctly, it should not matter if authors reference a hidden element with the value of aria-controls.

@carmacleod commented:

May be worth considering Heydon's article on aria-controls. :)

While I agree with most of the sentiment in Heydon's article, there are some fundamental missteps in his argument. First, it assumes that aria-controls is always intended to be a rendered property. In fact, in some cases, such as combobox, it is purely to establish a relationship that is helpful to assistive technologies when processing the accessibility tree. Second, the incorrect support of aria-controls that has long been available in JAWS does not necessarily infer that the property is entire useless.

That said, for some time, I have been on the verge of arguing for the deprecation of aria-controls. In every pattern where we recommend its use, I think that it is either redundant or that there is a potentially better way of establishing the relationship. But, for now that remains an open question to explore more deeply after we have solid support for all of ARIA 1.1 in all dominant assistive technology and browser combinations.

[accdc]

I thought we previously determined that aria-owns is not valid on native inputs because the accessibility tree cannot work properly on elements that don't support children. This is why aria-owns is not valid on img elements either. This was the whole reason for removing the aria-owns requirement from the design pattern and switching to aria-controls.

The reason why aria-owns is on the parent with role="combobox" in the 1.1 combobox design pattern, is because the widget that it controls might not actually exist within that container element, and the use of aria-owns will rearrange the accessibility tree so that widget will then appear inline with the edit field that controls it. This will break if you put aria-owns on the input edit field.

In case it's helpful, I wrote the following article about a year ago to discuss the differences between the 1.0 and 1.1 design patterns that explains many of these things.
https://www.levelaccess.com/differences-aria-1-0-1-1-changes-rolecombobox/