feat: banner component for medium priority information

[colabottles]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

Being able to add a role="log" (when notifications need to be read in order, e.g., stacking toast notifications on each other or role="alert" to toast notifications that are being logged to make them more accessible.

Describe the Use Case

This will ensure that when a toast is displayed on screen, its contents will be communicated correctly to assistive technologies, such as screen readers when using the correct role with the toast notification.

Describe Preferred Solution

I know role="status" is et on the inner .toast-content element but since there is an option should the developer want the toasts to be logged, I think it would work better as an option.

• • Same with aria-live="polite" (another feature request later) if someone needed to use aria-live="assertive" (which clears the speech queue of previous updates. "off" should be the default anyway).

Describe Alternatives

No response

Related Code

<ion-toast
  ...
  role="status | log | alert | off"
  ...
>

Additional Information

A toast to an accessible toast...
Defining ‘Toast’ Messages
Designing Toast Messages for Accessibility

It is also acceptable to use role="alert" in a toast notification to stop the current reading and notify the user of an alert. Focus should not move there. It had a drawback in that it could make a user feel stranded because of the interruption and consequential stoppage of reading by the screen reader, however.

If the alert has interactive controls, then it should be a modal and not a toast notification. Toast notifications should never have interactive controls in them.

[liamdebeasi]

Thanks for the report. Toasts in Ionic are intended to be subtle notifications that should not interrupt the user which is why we use role="status". If you need to use a more assertive presentation then we recommend using an ion-alert. The Toast Accessibility section has more information on this.

Some toasts in other UI libraries will allow you to use roles such as alert. However, Ionic follows the Material Design guidelines for toasts (also called snackbars) so we do not provide that functionality.

Can you clarify the pattern you are trying to implement and why ion-toast needs to be used?

[colabottles]

Thanks, @liamdebeasi

Snack bars, in my experience, have drawbacks that are far too many for them to be accessible to the minimum AA level of WCAG and generally have been poorly designed. So I am, as I build out an app with Ionic, trying to find a more accessible solution.

Snack bars, for the most part can:

• Change state erratically
• Disappear too quickly
• Can obscure other items and are hard to spot
• and can be inconsistent with where they are located

I would prefer to use an ion-toast at the top of the screen for consistency. If I am logging notifications (which my app may do) and if I have an alert (which it will), I would like to have those options to do so.

Toasts and snack bars are very tricky when it comes to accessible experiences and getting them to conform to WCAG standards, but I’d like to have that option, if possible, to do so.

[liamdebeasi]

Thanks for the additional information. My main concern about this feature request is it goes against how toasts are supposed to be used. I've seen toasts frequently used for time-sensitive or important notifications which lead to many of the issues you described in #27668 (comment). We can add the ability to use role="alert" on ion-toast, but that does not resolve the other issues that you noted.

Have you considered implementing a banner instead? That UI component has a higher priority and avoids many of the issues you noted. Here's a code snippet of how it could work: https://codepen.io/liamdebeasi/pen/MWzexaN

A few benefits of banners:

1. They are persistent.
2. They appear inline with the content, so they do not obscure anything.
3. They can appear in a consistent location (like at the top of the screen).

edit: Here's the Material Design banner: https://m2.material.io/components/banners

[colabottles]

Have you considered implementing a banner instead? That UI component has a higher priority and avoids many of the issues you noted. Here's a code snippet of how it could work: https://codepen.io/liamdebeasi/pen/MWzexaN

A few benefits of banners:

1. They are persistent.

2. They appear inline with the content, so they do not obscure anything.

3. They can appear in a consistent location (like at the top of the screen).

edit: Here's the Material Design banner: https://m2.material.io/components/banners

Thanks, @liamdebeasi for those resources. It does look like banner is the way to go in my case. I took a look this morning and it is the solution that works for me.

Toasts can be very tricky so it is more than likely going to take a lot of work if those roles were implemented, I do know that much. Much appreciated, talking this through.