Inline Notice Accessibility
Best Practices
Avoid having more than one high-priority notice visible at any time.
Avoid rendering high-priority inline notices on the server. For better discoverability, use a page notice instead. If you cannot use a page notice, then focus must be set on the inline notice.
Avoid using progress bars and spinners in conjunction with client-side notice.
Displaying a notice for a success or confirmation may not always be necessary. In the absence of an error message, a user can imply success (opinionated).
Interaction Design
Keyboard
Nested interactive elements (such as links) must be keyboard focusable.
A high-priority notice rendered on the server and visible on page load must receive focus. These cases should be rare; use a page notice when possible.
Screen Reader
Screen reader must not announce low-priority server-side notices.
Screen reader must announce client-side content changes to any type of notice.
Screen reader must announce client-side visibility change of a hidden notice.
If the notice is related to a control, the notice must be announced as the description of that control.
Pointer
Clicking or tapping a notice action activates its link or button.
ARIA Reference
| Attribute | Description |
|---|---|
| role="region" | Exposes the notice as a named landmark region. Use a label such as "Confirmation," "Information," or "Attention." |
| role="alert" | Announces a high-priority notice rendered on the client. Nest the alert inside the landmark region. |
| aria-describedby | Associates a notice with the control it describes. |