Alert Types: Notes for Better UX, Decision-Making and Accessibility
Let’s talk about alerts and how they are supposed to work. I was recently in a discussion about them at work, and to better prepare myself for a discussion with the product team and C-suite officers, I should refresh myself about them. So here are my notes about them.
Interactive & non-interactive
There are two types of alerts: interactive and non-interactive.
Interactive alerts
Interactive alerts require user interaction, which is usually to confirm or provide an input and to capture the user’s attention. They must be persistent, meaning that they are visible until an action that dismisses it is performed by the user. Additionally, it should guide the user through the required action.
For accessibility, alerts require that the focus moves to the alert and focus is trapped. It should not be an aria-live region. The first focusable element in the alert should be focused on. It should be dismissible via keyboard by pressing the Escape key. When the alert is dismissed, focus should return to where it was prior to being moved to the alert.
Non-interactive alerts
Non-interactive alerts are for informational messages that don’t require an action. These include form validation, status updates, or system notifications. They can be auto-dismissed or persistent. It depends on the priority of the message. Most of the time, they are implemented to auto-dismiss after a certain time period. 4 seconds is what is recommended. These alerts should also have an action to dismiss, such as a close button or the ability to swipe it away. The alert should not disrupt the user’s attention.
For accessibility, non-interactive alerts need to be announced to screen readers by using a live region. They should also appear in the DOM but not receive focus.
For auto-dismissing, the timing is important. It’s recommended that the alert stay open for about four to five seconds or longer. The reasoning is:
Users may miss it.
Users will have different reading speeds.
User with Visual or cognitive limitations may need more time to read the message.
It’s highly recommended not to auto-dismiss non-interactive alerts, but as with most things, it really depends on the importance of the message.
Alert Decision Table
| Alert Type | What It's For | When to Use | User Experience | Primary ARIA Role | Focus Management | Persistence | Announcement | Best For |
|---|---|---|---|---|---|---|---|---|
| Interactive Alert | Getting user input or decisions | Requires user action/response | User must stop and respond | role="alertdialog" | Must move focus to first control | Must be persistent | Not applicable (focus-based) | Error fixes, confirmations, critical decisions |
| Non-Interactive Alert | Giving users critical information | Important information, no user action required | User continues their current task | role="alert" | Don't move focus | Should be persistent | Announce immediately | Connection lost, security warnings, system errors |
| Non-Interactive Status | Giving users general information | Information only, no user action required | User continues their current task | role="status" | Don't move focus | Can auto-dismiss (4+ seconds) | Announce politely | Status updates, confirmations, notifications |
Conclusion
Overall, I think a basic alert is relatively straightforward. Like most things, it all depends on what kind of alert you are implementing and the additional features that may need to go with it. For example, you may be asked to stack multiple consecutive alerts. During one of the discussions at my work, a stakeholder brought up the idea of having a timer in the alert. You need to think a little about how that would change things. If you want to meet WCAG timing criteria, you would have to devise a way to pause or extend the timer. That’s just an example of how things can get complicated in their development.
I hope these notes about alerts have been helpful.
