The Combobox 1.0 design pattern references incorrectly include aria-owns instead of aria-controls.

[accdc]

As we discussed in the APG meeting last week, the APG design pattern for the Combobox 1.0 markup does not take into account that aria-owns was changed to aria-controls to correct long standing accessibility API issues when applied to elements that do not support child elements, such as the HTML input element.

It was the filing of this issue years ago against the 1.0 spec that led to the creation of the 1.1 Combobox design pattern, yet none of the 1.0 design pattern references include this change within the 1.1 ARIA spec. As a result, this issue continues to negatively impact the accessibility of this widget globally, just because the spec was not changed to reflect this going forward.

This is primarily an editorial change, to simply replace the aria-owns references to aria-controls instead, and that is all that needs to be done. By changing this within real world implementations, the accessibility of these widgets suddenly become accessible across all mainstream platforms, whereas if this change is not done, serious accessibility issues will always continue to exist otherwise.

This change requires no action by the browser implementors, because doing this within the markup already results in the desired accessible results across all mainstream browsers already.

Example:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Simulated,%20Readonly)/demo.htm

[accdc]

Another example that includes the use of standard HTML input elements can be tested here as well:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Comboboxes/ARIA%20Comboboxes%20(Native%20Inputs,%20Editable%20and%20Readonly)/demo.htm

[jnurthen]

I'm still not clear on what needs to change. If it is as simple as you are proposing a PR would help clarify.

[mcking65]

While I agree with @accdc on the fundamentals of this issue, I don't think this is editorial. We would not have the 1.1 pattern if this change would have been permitted in ARIA 1.1. Some members of the ARIA WG, during the 1.1 cycle, were concerned that the controls relationship was insufficient for establishing a relationship between the input of a combobox and the popup of a combobox. Because of those concerns, the 1.1 pattern was added.

The downside is that nearly two years after 1.1, there still is no support in screen readers for the 1.1 pattern. Ironically though, if you make the simple tweak to the 1.0 pattern that Bryan suggests, we get all the benefits of the 1.1 pattern, and we get them now because it already works with screen readers. I don't think the people who objected to just making the simple tweak foresaw this.

So, the ideal change is to eliminate the 1.1 pattern and simply replace aria-owns with aria-controls in the 1.0 pattern. I will have this PR ready before the F2F. In particular, we will need the support of @melanierichards because UIA is one of the APIs where mapping a combobox in this way appeared to introduce some kind of complication that concerned at least 3 former WG members.

[melanierichards]

@mcking65 @accdc is my understanding correct that the updated 1.0 pattern would include a text input, with a couple attributes applied like so:

<input type="text" role="combobox" aria-controls="myListbox" etc />

vs the combobox role applied to an ancestor of the text input (as is the case in 1.1)? If that were so, that wouldn't align with structural expectations for comboboxes in UIA and I don't think would align either with the current expectations of ARIA for combobox and its required owned elements. If this is not the proposed change, probably easier to review a PR to grok the suggested update.

[zcorpan]

#1051 is merged.