Toast notification and Focus Management

[sirrah-tam]

Expected behavior

As a keyboard-only user, I'm expecting to dismiss the Toast notification and have keyboard focus be brought back to the triggering control (last known control that triggered the notification) so I can resume navigating the search results.

Actual behavior

After dismissing the Toast notification, focus is lost and is reset to the beginning of the page. I now have to navigate all of way back to where I previously was in order to resume navigation.

Steps to reproduce the issue (an example)

1. From search results page, save an item to your workspace.
2. Observe keyboard focus on Toast notification and navigate forward (Tab) to the dismiss button
3. Activate it by pressing Enter
4. Observe keyboard focus after pressing Tab to go to next focusable element.
5. Return to previous location

Screenshots or code

Pharos version

Production

Your environment

• OS: macOS, Windows
• Browser: Chrome, Firefox, Safari
• Version: 97.0, 105.0.2, 16.0

Additional information

Developers can use the element.focus() method to programmatically set focus. Where focus should be placed may be different in certain situations, but this is similar to how modal dialogs work and when dismissed focus should be returned to the control that initially triggered the modal.

This also impacts screen reader users as focus is moved to the Toast notification and similarly when dismissed focus is lost and either is placed randomly on the page or back to the beginning of the page.

There may also be additional accessibility considerations:

• Possible aria-live region to announce content and not rely on pulling users focus
• Persistent vs temporary notifications

[brentswisher]

Just a note I thought might help with some additional info. I vaguely remembered the WordPress editor had some similar accessibility issues when adding a "toast" component. I took a look and while it is still unsolved in that project, there was some interesting reading linked I thought I might surface here in case it was helpful at all:

• Bootstrap's toast accessibility notes
• PR in Google's "Web Stories" product on making toasts accessible
• A decent overview of the inherent difficulty in making toasts accessible. (Note: This references Google's proposal to add a new element for toasts, which I was not aware of but looks to have been abandoned.)

[daneah]

Just seeing your notes; thanks a bunch for providing those @brentswisher!

[ymouzakis]

We are having this issue inside the Workspace as well. Example: User does Workspace action that generates a toast and then page focus gets lost. I was chatting with @sirrah-tam and we discussed making a toast that never takes focus from the page. This is acceptable to do when there is no interactive elements in the toast. Screen readers will pick up the toast so long as the correct alert attributes are on the toast; focus is not needed. I think this is a pretty cheap way to resolve this issue.

[daneah]

After #503, the remaining issue here is that we should only send focus to a toast in the first place if it contains interactive elements (this may be hard to detect). We do have a mechanism as part of #503 to send focus back to the desired location, however.