You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 5, 2024. It is now read-only.
In working on #3859 and #4914, I came across an issue that has existed for a while (I've mentioned it to @rschmukler a few times):
The options for an mdSelect are not in the DOM at all until you click or use the keyboard to activate it. For screen readers, this means a relationship cannot be established between the select and the options it controls, causing an error in Chrome's A11y Developer Tools:
[Severe] Elements with ARIA roles must ensure required owned elements are present (1)
Furthermore, when the options are rendered, they go into a separate part of the DOM. We can bind a relationship with aria-owns, however, that attribute also requires the matching element to be rendered at load time. When I went to do the work required for #3859, I got even more errors in the Chrome A11y audit stemming from this issue. So the problem isn't going away.
Recommended fix: inject the options on page load so the required ARIA relationships can be established. We can then test aria-owns on mdSelect and decide if the options are accessible enough when rendered in a separate part of the DOM.
For async, we could put in at least one option to start (like a placeholder). I'm not sure how accessible this will be, since it might not refresh the accessibility tree reliably, but it's worth a try.
The text was updated successfully, but these errors were encountered:
Role combobox also technically requires an owned element with role "textbox" (because a combobox normally has an editable text field at the top), though from your investigation in #3859, I think that's not really worth addressing (if NVDA and JAWS both consider the built-in <select> as a "combobox" even though it's not). But it does mean that the audit will continue to fail even if this is fixed.
This highlights some of the gaps with native controls and ARIA support. Even though role=combobox is suggested as "a presentation of a select" in the ARIA spec, it doesn't fit the use case where there is no text input, or one that needs to be multiselectable. I think it's fine to use role=listbox in this case, since it will at least tell a screen reader user that they are interacting with some kind of list control.
In working on #3859 and #4914, I came across an issue that has existed for a while (I've mentioned it to @rschmukler a few times):
The options for an mdSelect are not in the DOM at all until you click or use the keyboard to activate it. For screen readers, this means a relationship cannot be established between the select and the options it controls, causing an error in Chrome's A11y Developer Tools:
Here is the part of the ARIA spec this error refers to: http://www.w3.org/TR/wai-aria/roles#mustContain
Furthermore, when the options are rendered, they go into a separate part of the DOM. We can bind a relationship with
aria-owns
, however, that attribute also requires the matching element to be rendered at load time. When I went to do the work required for #3859, I got even more errors in the Chrome A11y audit stemming from this issue. So the problem isn't going away.Recommended fix: inject the options on page load so the required ARIA relationships can be established. We can then test
aria-owns
on mdSelect and decide if the options are accessible enough when rendered in a separate part of the DOM.For async, we could put in at least one option to start (like a placeholder). I'm not sure how accessible this will be, since it might not refresh the accessibility tree reliably, but it's worth a try.
The text was updated successfully, but these errors were encountered: