Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
accdc opened this Issue Jan 28, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@accdc
Copy link

accdc commented Jan 28, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.