Do you place toast notifications where users expect them?

A toast notification is small. Its impact is not.

Poor placement creates confusion. Good placement feels invisible and intentional.

If users hesitate for even a second wondering “Was that my system or the app?”, you have introduced friction.

For most modern web applications, there is a clear default: Bottom center the safest and least obstructive choice.

Analysis of all six positions

What real web apps do

There is no universal convention. Different products optimize for different layouts, platforms, and interaction patterns.

The important takeaway is consistency, not imitation. At SSW, the default is bottom center because it gives a stronger cross-platform baseline and avoids the primary OS notification zones on both platforms (macOS top right, Windows bottom right).

Recommendations

✅ Choose bottom center

• Aligns with Material Design and modern cross-platform UX
• Works consistently on desktop and mobile
• Avoids macOS top-right and Windows bottom-right OS notification zones
• Common in products like Figma and X
• SSW standard for new web applications

👍 Bottom right is a strong alternative

• Common in enterprise SaaS apps
• Familiar to many desktop-first users
• Strong fit when your layout keeps key actions away from the lower-right corner
• Validate carefully on Windows, where OS notifications can appear in the same corner

⚠️ Use caution with top right

macOS Notification Center sits in the top-right corner of every Mac screen. Placing in-app toasts in the same zone can create two compounding problems:

• OS-level notifications can physically overlap and hide in-app toasts
• Users cannot reliably distinguish between a system notification and an app notification, breaking trust and clarity

Only use top-right placement when platform constraints and user testing clearly justify it.

Accessibility requirements

Toast placement is not just visual. It is semantic. Implementation must also satisfy WCAG 2.2 requirements.

Follow WCAG guidance:

• Use role="status" for success and informational toasts
  • Polite ARIA live region
  • Screen readers announce after the current task
• Use role="alert" for errors
  • Assertive
  • Screen readers interrupt immediately
• Minimum display time: 4 seconds (WCAG 2.2 - Success Criterion 2.2.1 Timing Adjustable)
• Never auto-dismiss error toasts
• Do not cover primary CTAs or form fields

Text content structure

Position is only half the UX. The wording inside a toast determines whether users understand what happened and what to do next.

Use these text structure components:

• Message / Body (Mandatory): A concise, usually single-sentence message that explains the outcome, such as success, failure, or a status update.
• Headline / Title (Optional): A brief summary like "Success" or "Error" shown before the message when extra emphasis is helpful.
• Action Label (Optional): Short button text like "Undo" or "Retry" for a directly related next step.

Keep all toast text in sentence case, and keep titles concise and to the point.

Examples:

• ❌ Bad message: “Something went wrong.”
• ✅ Good message: "File uploaded."
• ✅ Good title + message: "Error. Could not save changes."
• ✅ Good action label: "Retry"

Reference: Carbon Design System - Notification style

If you are building a modern SaaS or enterprise web application, default to bottom center.

Small details build trust. Predictability reduces friction.