Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
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
Within the ARIA 1.0 Combobox design patterns, the aria-owns attribute is used on input elements, which does not take into account that using aria-owns on elements that do not support child elements has been proven to cause critical accessibility issues in mainstream browser / screen reader combinations.
This follows the same logic that aria-owns cannot be used on img elements for the same reason, when doing so will introduce critical accessibility issues if done.
It is for this reason that aria-controls was introduced to be used with the ARIA 1.1 combobox design pattern on input elements instead of aria-owns, not counting all of the other differences involved between the two design patterns.
The same logic is still valid on the 1.0 design pattern, and though this is a slight deviation, it is meant to address a correction that was done in ARIA 1.1 that translates without any negative impact to 1.0.
I have recently encountered a live example where the use of the aria-owns attribute in this manner is making the combobox widget impossible to use in IE11, Firefox, and Chrome using both JAWS and NVDA, which suddenly becomes accessible when aria-owns is changed to aria-controls instead.
It is clear that assistive technologies and browsers are not going to go back and add support for broken features in prior versions of the spec, so it is fflawed logic to introduce a design pattern that is provably broken when it does not include a fix that was specifically introduced to correct this issue in a subsequent version of the same spec.