fix(material/select): make VoiceOver read options for selects in dialogs

[jelbourn]

Fixes #20694

@zelliott noted that this issue was caused by aria-modal preventing
VoiceOver from accessing the select's listbox overlay. He suggested
using aria-owns to re-parent the overlay element to the select
trigger. I tried this and it works great.

[crisbeto]

LGTM, but the lint check is failing.

[zelliott]

After having refreshed myself on the various combobox patterns, you're right that this does stray from ARIA 1.2 (which is what I'm guessing you're following here). I'm concerned that adding aria-owns here might cause some of the issues that the ARIA 1.0 combobox encountered, but I don't quite know enough about comboboxes to know for sure. @stevenyxu likely has some thoughts here.

[stevenyxu]

I didn't realize the fix was already done so I took a stab at it and fwiw did confirm it fixes the issue. Here's my snippet (slightly different flavor than your fix but very similar):

<!-- removing aria-modal makes everything work, even if aria-owns is removed -->
<div aria-modal=true role=dialog>
  <button onclick="trigger.setAttribute('aria-activedescendant', 'opt1')"
          id=trigger
          role=combobox 
          aria-controls=listbox>
    select trigger
  </button>
  <!-- removing this breaks things, assuming aria-modal is set -->
  <div aria-owns=listbox></div>
</div>
<div role=listbox id=listbox>
  <div role=option id=opt1>opt 1</div>
  <div role=option id=opt2>opt 2</div>
</div>

+1 to Zack's point about the risk of appearing like a 1.0 combobox. In my separate discussions with Deque to get axe updated to permit the 1.2 pattern (dequelabs/axe-core#2505), one potential that was raised was to warn when people set aria-owns to nudge them to the 1.2 pattern instead. By being stuck in the middle here, overzealous heuristics may match you in a way you don't intend. An easy alternative is to put aria-owns on a roleless sibling to the mat-select, which is widely supported and doesn't result in mixing the 1.0 and 1.2 patterns. Of course, the combobox being the component's host element makes this slightly awkward.

[jelbourn]

@stevenyxu I moved aria-owns to a child element of the combobox without a role (.mat-select-trigger). This seems to work just as well on VoiceOver, NVDA, and ChromeVox.

[jelbourn]

Forgot to link the demo: https://material2-dev.firebaseapp.com/select

[zelliott]

If I understand @stevenyxu correctly, he recommended placing the aria-owns on a sibling of the combobox to avoid mixing the 1.0 and 1.2 patterns (but noted this would require some refactoring). As of now, aria-owns is still a child of the combobox, so IMO this still runs the risk of being flagged in an Axe check or as a WCAG failure potentially.

Regardless, I think this PR is still an improvement over the status quo, which renders popup listboxes wholly inaccessible within modal dialogs, so I wouldn't block on this concern.

[jelbourn]

Yeah, the only way I see the sibling approach working is if we manually insert a DOM element, which obviously isn't ideal. I figure it's better to hold off on that and see if anyone actually reports a problem.

[rameshworsht]

This PR does not resolve the main issue. Select component is not being read by screen readers. The solution would be to follow the suggestion by @zelliott.

[jelbourn]

@rameshworsht feel free to file a new issue if you have steps to reproduce. I confirmed that this fix worked for VoiceOver, NVDA, and ChromeVox.

[rameshworsht]

@jelbourn I used the like that you provided for the demo: https://material2-dev.firebaseapp.com/select and test it. Here is the GIF of the test.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}