fix(material/snack-bar): flaky screen reader announcements for NVDA/JAWS

[haywoodsloan]

Fixes a bug where NVDA won't announce polite snack bars and JAWS won't announce any.
This is because the live region (snack-bar-container) was added to the DOM, marked as a live
region, and content was added to it in the same operation. Some screen readers require the live
region to be added to the DOM, some time to pass, then content can be added. Now the snack bar
content is added to an aria-hidden div then, 150ms later, moved to a div with aria-live defined.
This won't cause any visual changes and keeps the snack bar content available immediatly after
opening. Also, no longer using the alert or status roles. Instead just using aria-live as testing
showed that NVDA will double announce with the alert role and JAWS won't announce any button text.

BREAKING CHANGE: matSnackBarHarness.getRole() replaced with .getAriaLive() due to using aria-live
rather than the alert and status roles.

[crisbeto]

My understanding is that this will only be a problem for snack bars that don't have an announcementMessage. What if, instead of setting a role on the container, we announced the textContent of the container with the LiveAnnouncer, when an announcementMessage isn't specified? The advantage would be that we won't have to add the extra timeout and we'll avoid having to move DOM nodes around.

[haywoodsloan]

I had previously considered an approach like you describe, using textContent and LiveAnnouncer. There were a couple of concerns that dissuaded me though:

1. Screen readers will announce more than just the text content of a live region, this includes things like aria-label, aria-describedby, aria-disabled, aria-expanded, etc. Each screen reader has a slightly different language it uses to describe these attributes so matching what a users typically expects to hear from their screen reader isn't possible.
2. Updates to the user's snack bar content after the initial announcement wouldn't automatically be announced. Could be a scenario where they open a snack bar from a custom component which changes content based on some external event.
3. If the real content of snack bar appears late enough after the entrance animation ends, could capture the wrong text content and announce nothing. E.g. open a snack bar from a custom component that defer loads it's content.

Maybe a MutationObserver could address 2+3, but not 1. Given that and the extra complexity to filter mutation events to only announce changes a screen reader would for a normal live region, I think the DOM manipulation is cleaner solution.

[jelbourn]

Are the isBrowser check and the instanceof HTMLElement strictly necessary?

[haywoodsloan]

The instanceof HTMLElement check is because document.activeElement is type Element which doesn't implement focus. So I check to make sure the active element is of type HTMLElement and therefore focusable.

I found without including the isBrowser check I would get some view_engine test failures related to document not existing. For mdc-snack-bar with the switch back to using setTimeout the call to _screenReaderAnnounce is already nested in a isBrowser check, so I've removed the redundant one. For snack-bar I've kept the check because it isn't done elsewhere in the component.

Here's an example test failure: https://app.circleci.com/pipelines/github/angular/components/13171/workflows/d5670bcf-b85d-4721-8372-86b96b5f872f/jobs/187667/parallel-runs/0/steps/0-107

[jelbourn]

Overall looks good, just one last comment about the extra change detection cycle from setTimeout

[jelbourn]

LGTM

Caretaker note: let me know if this results in a lot of failures

[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.}