Toast scroll issue

[HartiganHM]

Hey, all!

We've noticed an issue with the Toast component and scroll behavior. In short, this is what happens:

• A Toast appears on the page via toaster.push
• The user scrolls further down the page (either manually or through automatically via something like element.scrollIntoView)
• Once the Toast is automatically or manually dismissed, the user is snapped back up to where the Toast was originally rendered

I've recreated the issue in a CodeSandbox here. The handleMakeToast method creates the new Toast and auto-scrolls to an element at the bottom of the page. Once it is dismissed, you can see the issue. I've tested that this also occurs if the scrollIntoView code is commented out and you manually scroll to the bottom once the Toast is rendered.

This is currently happening in our application and, though it isn't a breaking issue and happens only with edge cases, it would be great to figure out a workaround/solution whenever possible.

Please let me know if I can provide any further details! Thank you!

[TheSisb]

Hi @HartiganHM,

I'm not seeing Toast imported or used in the example linked above. Did you make sure to save the changes? (Open it in incogneto to verify)

[HartiganHM]

Hey, @TheSisb, sorry about that! Everything should be good to go now 👍

Thanks!

[TheSisb]

Hi again @HartiganHM,

Upon looking into this and chatting with the team, this is an unfortunate side effect of the design of toasts that we can't really change. The way Toasts are designed is that, for accessibility, they steal focus when they appear and restore focus when they are dismissed. While they're visible, you scroll the page and when it is dismissed, upon restoring focus, the browser naturally jumps back to the focused element to bring it into view.

[HartiganHM]

Good eye. We specifically block changing that behavior because we don't / did not have a good use-case for enabling it, since we steal and restore focus for accessibility.

Based on this, does that mean the documentation needs to be updated?

...it is important that we restore it so that the screenreader user doesn't get lost.

I think there may have been some miscommunication on my part here. I completely agree with this. My point maybe applies more accurately to an auto-dismissal (though also happens on manual dismissal, as I'll illustrate further below):

• Toast appears and focus is set
• User does not manually dismiss the Toast
• User navigates elsewhere on the page and interacts with another focusable element
• Toast auto-dismisses and steals focus back, but restores focus to the original element, not the new focusable element further down the page

You can recreate this in the Sanbox provided by clicking on the Button that says "Preferences" after having been auto-scrolled to the bottom of the page.

Additionally, for what it's worth, if I'm interacting with the page via keyboard and choose not to dismiss the Toast and instead tab elsewhere, I would expect focus to be restored, which currently isn't the case. Maybe a non-issue, but something to think about.

As for the reduced motion, I may have made a false equivalence. What I was trying to communicate was that if a user chooses to ignore a Toast and continue moving down a page, it would be jarring to be zipped back up to where the notification was rendered.

---

I've added a basic walkthrough of the UI/UX we've built, as well as some GIFs to illustrate it more clearly. As for your points, we did consider using an Alert, but it didn't look right with what we're building and a Toast was much less obtrusive. We did consider the fact the Toast component is typically triggered as a result of user action, which is the case as we have it implemented. To give you a quick run down:

• A user is attempting to reach support, but is presented with a search query field as a means of self-service
• The user is then presented with articles to help them with their specific issue
• If none of these articles helps, the user can chose to "Continue"
• Upon clicking continue, the user has a number of ways to contact support
  • If a contact option is unavailable, we show a Toast notifying them that it is down
  • At this point, let's assume the user does not dismiss the Toast
• The user selects a different contact method, which reveals a form beneath the contact options and scrolls them down to the top of the form
• At this point, two things can happen with the Toast:
  • The user manually closes the Toast and is now scrolled away from the form
  • The user continues to ignore the Toast and is scrolled away from the form once it auto-dismisses

I think this pretty succinctly communicates what we're running into. For us, it seems like a pretty poor user experience, but maybe there's something we're missing/misusing in our implementation. If you need any other details or have any thoughts about how we could remedy the issue, we're all ears 🙂

Toast is automatically dismissed and scrolls user up after interacting with a form element

Toast is manually dismissed and scrolls user up after interacting with a form element

[TheSisb]

Based on this, does that mean the documentation needs to be updated?

Good call, I made a note to do that.

I shared the preview gifs with my team. Upon reviewing them, we believe that an inline error under the disabled button would be the best possible solution here. A Toast should be used to notify you about an action you just took; in this case the user hasn't really taken a direct action for customer support. Our Alerts have guidance that say they should be used to inform you about system outages. However I think an inline error message right under the disabled button would be the most obvious as to why it is disabled in this instance and solves the problem at hand.

Hope this helps some, let us know what you think.

[HartiganHM]

I've relayed your suggestion to the rest of the team and our Product Manager, so I'll circle back when I hear from them. Thanks for the help!

I would still like your or the team's thoughts on the below point:

Toast auto-dismisses and steals focus back, but restores focus to the original element, not the new focusable element further down the page

If we assume that the Toast truly "restores" focus, shouldn't this be on the last focused element? Technically, I see how this would be difficult to accomplish and maybe an assumption that the user would move somewhere else before the Toast is dismissed. However, it seems like just as much of an assumption to assume that a user won't move somewhere else before a Toast is dismissed.

I understand the accessibility considerations and certainly appreciate them, however it feels to me that there should be some amount of flexibility with how focus is set/stolen/restored.

[TheSisb]

I hear you, this isn't ideal by any means. Unfortunately I don't believe it's feasible for us to maintain a complete focus management solution at this time. They're extremely complex, and even if we attempted it we'd run into a dead end if we just consider Console. Immediately issues around iframes and the scoping/privileges around that would cause odd behavior.

As a last resort for consumers of Paste, I would probably lean into recommending using the Toast component standalone, then rolling your own modified Toaster and useToast hook. You'd get the styles and be able to plug custom behavior to the product you're working on by leveraging what we have already. I was thinking about suggesting that, but your preview gifs made the team think of a much simpler approach, which hopefully also improves the UX.

[HartiganHM]

Hey, @TheSisb, thanks for the updates! I completely understand/empathize with the technically difficulty of what's being done. (And if it hasn't been said enough, thank you to you and the Paste team for all of your hard work!)

I think a hand-rolled solution using the Toast as a base is probably a solution worth investigating. Our technical implementation at this point is light enough that I think we could get it to work.

I'll follow-up with what we land on once it's completed, but we can go ahead mark this as solved ✅

Thanks for the patience and insight with this issue!