components icon indicating copy to clipboard operation
components copied to clipboard

Notification pattern

Open jpzwarte opened this issue 3 years ago • 7 comments

Create a new snack bar web component.

This component is for displaying "notifications" inside the web application. Some examples:

  • Asynchronous feedback from a previous task
  • Feedback from an external process

Other implementations:

  • https://dna.iddinkgroup.com/?path=/story/core_overlays-snack-bar-examples--api
  • https://material.angular.io/components/snack-bar/overview
  • https://nordhealth.design/components/toast-group/
  • https://web.dev/building-a-toast-component/

Requirements:

  • It should provide an API for displaying notifications
  • Displaying notifications should be handled by a "controller" component (<sl-snack-bar-controller>)
  • API & controller should be loosely coupled (events)
  • Controller should handle multiple notifications at the same time (stack them)
  • It should be accessible (aria-live?)
  • For this initial version, only allow message: string and autoClose: boolean, type: 'info' | 'success' | 'error'
### CFA Interest
- [ ] Magister
- [ ] TEAS
- [ ] ETSL

jpzwarte avatar Jan 09 '23 08:01 jpzwarte

https://loihdefactor.com/fi/2022/04/29/building-testing-tools-for-aria-live-regions https://aerotwist.com/blog/flip-your-animations/

Diaan avatar Jan 10 '23 09:01 Diaan

I believe this to be the most important resources on an accessible Toast:

  • https://adrianroselli.com/2019/06/scraping-burned-toast.html
  • https://adrianroselli.com/2020/01/defining-toast-messages.html

This quote regarding accessibility is worth noting:

Few (none that I have found so far) of the existing toast or toast-like notification patterns in the wild will pass a WCAG audit. Instead of reviewing each of the ~50 examples, I am going to break down some of the broader concepts and risks that you can bear in mind when writing your own toast-like notification or reviewing one to use in your project.

And 2.2.1: Timing adjustable is the reason itslearning we stopped suggesting to have a Toast component in our Component Library.

furstenberg avatar Jan 10 '23 14:01 furstenberg

Thanks for these links @furstenberg Really interesting!

https://adamsilver.io/blog/the-problem-with-snackbars-and-toast-messages/

Diaan avatar Jan 11 '23 07:01 Diaan

I have many more related to the other components that are going to be made, so let me know if they are of interest.

Itslearning have spent quite some time on accessible components.

furstenberg avatar Jan 11 '23 14:01 furstenberg

@furstenberg Of course we're interested in your expertise! Feel free to keep commenting on issues and certainly join in the discussions: https://github.com/sanomalearning/design-system/discussions

We will keep doing our research before each component we make so if we have specific questions regarding an interaction we'll get in touch!

Diaan avatar Jan 11 '23 16:01 Diaan

📝 put back on backlog until we've figured out how (if) we should make this in an accessible way

Diaan avatar Jan 12 '23 07:01 Diaan

Research done:

If you find yourself saying, Hey, if my screen reader, zoom, or keyboard-only users miss some of these messages, it’s not a big deal then you have a larger question to ask — do you even need those messages?

Researching how to build an accessible snack bar/ toast component we found rather a lot of comments and articles about the problems of making it accessible. Some of the recommendations also seemed to contradict each other.

Biggest downsides

  • People using screen magnifiers might miss something that happens in a part of the screen they're not focused on. (toast in the bottom right corner after clicking in a button in the top left part of the screen
  • Temporary messages (that disappear automatically) might not allow people with visual/reading/cognitive challenges enough time to read and process the text before it disappears
  • Things like aria-role = alert and aria-live = assertive will help to notify people using a screen reader that there is a message, but making these messages both non interrupting and easy to dismiss (or reread) is a difficult balancing act.
  • How can we create (and communicate) a consistent way to interact with the messages for keyboard users; showing a message shouldn't move the focus away from where the user currently is in the page, but it should also be easy to access a message without going through the entire page.

Possible alternatives to toast messages

  • Inline banners
  • Banner at the top of the page
  • Notification center with messages accessible via a menu item

Challenge This discussion is an attempt to find accessible solutions for all scenarios in which we would (without thinking about accessibility) use a toast message.

Articles and resources

  • https://adrianroselli.com/2020/01/defining-toast-messages.html
  • https://adrianroselli.com/2019/06/scraping-burned-toast.html
  • https://www.w3.org/WAI/ARIA/apg/patterns/alert/
  • https://adamsilver.io/blog/the-problem-with-snackbars-and-toast-messages/
  • https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html
  • https://twitter.com/adambsilver/status/1671771296257163264
  • https://adamsilver.io/blog/the-problem-with-toast-messages-and-what-to-do-instead/

Diaan avatar Mar 28 '24 09:03 Diaan