Docs: clarify toast accessibility guidance

Author: Akash-kirar

site/src/content/docs/components/toasts.mdx

@@ -13,6 +13,10 @@ Things to know when using the toast plugin:
 - Toasts are opt-in for performance reasons, so **you must initialize them yourself**.
 - Toasts will automatically hide if you do not specify `autohide: false`.
 
+<Callout type="warning">
+**Consider whether a toast is the right pattern before using it.** Toasts don’t receive focus when they appear and often disappear automatically, so they work best for brief, supplemental updates. For validation errors, task-critical guidance, or actions that users need to complete, prefer a more persistent pattern such as the [alert component]([[docsref:/components/alerts]]).
+</Callout>
+
 <Callout name="info-prefersreducedmotion" />
 
 ## Examples
@@ -260,7 +264,7 @@ You can also get fancy with flexbox utilities to align toasts horizontally and/o
 
 ## Accessibility
 
-Toasts are intended to be small interruptions to your visitors or users, so to help those with screen readers and similar assistive technologies, you should wrap your toasts in an [`aria-live` region](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions). Changes to live regions (such as injecting/updating a toast component) are automatically announced by screen readers without needing to move the user’s focus or otherwise interrupt the user. Additionally, include `aria-atomic="true"` to ensure that the entire toast is always announced as a single (atomic) unit, rather than just announcing what was changed (which could lead to problems if you only update part of the toast’s content, or if displaying the same toast content at a later point in time). If the information needed is important for the process, e.g. for a list of errors in a form, then use the [alert component]([[docsref:/components/alerts]]) instead of toast.
+Toasts are intended to be small interruptions to your visitors or users, so to help those with screen readers and similar assistive technologies, you should wrap your toasts in an [`aria-live` region](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions). Changes to live regions (such as injecting/updating a toast component) are automatically announced by screen readers without needing to move the user’s focus or otherwise interrupt the user. Additionally, include `aria-atomic="true"` to ensure that the entire toast is always announced as a single (atomic) unit, rather than just announcing what was changed (which could lead to problems if you only update part of the toast’s content, or if displaying the same toast content at a later point in time). Because toasts don’t receive focus and may be dismissed automatically, they shouldn’t be the only way to present information users may need to act on or review later. If the information needed is important for the process, e.g. for a list of errors in a form, then use the [alert component]([[docsref:/components/alerts]]) instead of toast.
 
 Note that the live region needs to be present in the markup *before* the toast is generated or updated. If you dynamically generate both at the same time and inject them into the page, they will generally not be announced by assistive technologies.
 
@@ -269,8 +273,8 @@ You also need to adapt the `role` and `aria-live` level depending on the content
 As the content you’re displaying changes, be sure to update the [`delay` timeout](#options) so that users have enough time to read the toast.
 
 ```html
-<div class="toast" role="alert" aria-live="polite" aria-atomic="true" data-bs-delay="10000">
-  <div role="alert" aria-live="assertive" aria-atomic="true">...</div>
+<div class="toast" role="status" aria-live="polite" aria-atomic="true" data-bs-delay="10000">
+  ...
 </div>
 ```