Use alerts if you need to communicate to users in a prominent way to take action or be made aware of important information that does not interrupt their experience.
- Alerts relevant to an entire page should be placed at the top of that page, below the page header.
- Alerts related to a section of a page, like a modal, should be placed inside that section, below any section heading.
- Alerts related to an element more specific than a section should be placed immediately above or below that element.
When displaying an alert, push the content below it down (could be the page content below or the section content).
- Do use alerts thoughtfully and sparingly for only the most important information.
- Do keep the messaging concise, scannable, and actionable (if needed).
- Do focus messaging on a single topic or required action to avoid overwhelming the user.
- Don't use alerts for marketing information.
- Don't use redundant terms. As an example, saying "successfully" in alerts that confirm a successful action is redundant.
- Don't include more than one or two links per alert. The primary action should be listed first.
- Don't use ephemeral messaging to convey important context like form errors.
- Don't display more than one alert at a time.
- Be scannable, brief, and to the point.
- Be written in a human-readable language.
- Be as specific as possible. A generic statement like, "Something went wrong" doesn't provide enough context to help ground the user.
- Include constructive advice on how to fix a problem.
- Be no more than one or two sentences.
- Be written in Sentence case. Capitalize the first word in the heading and proper nouns only.
- Use appropriate punctuation. Each message should end in a period.
Use a success alert when notifying the user that a task has been completed. They can include follow up actions if necessary related to the task.
Your username and a link to reset your password have been sent to your email address.
If this email does not arrive within a few minutes,
Inform the user of the completion of their task in past tense and what they can expect next.
Use an info alert when notifying the user of neutral information. They can include links for users to take action.
Use a warning alert to inform users of an instance that will directly impact the ability for them to complete their task. It should provide a reason for the warning, a recommended next step, and a way to contact us. Warnings are meant to be less alarming than error alerts.
Use an error alert when the user has submitted something the system can't accept, preventing them from continuing or when there is a system error that needs immediate attention.
To provide extra clarity, doubling on the use of Alerts and inline validation helps people quickly notice, find, and remedy errors.
If the user made an error the messaging should provide a reason for the alert, a recommended next step, and a way to contact us. If there are multiple errors, summarize them in a logical order (e.g. for forms that are missing several required fields from the user).
Please correct the following highlighted fields before continuing.
- Username
- Password
- Accept JSTOR's Terms and Conditions
If there is a system error or something went wrong on our end, be apologetic, take the blame, provide a reason for the alert, and a way to contact us.
To allow for alerts to be closed, alerts have a button rendered when the attribute closable is enabled.
- Ensures alerts are perceivable by assistive technologies by using appropriate ARIA roles (e.g.,
role="alert"for dynamic messages). - Provides predefined color schemes for different alert types (e.g., success, error, warning, info) that meet contrast requirements.
- Supports dismissible alerts with accessible close buttons that have proper labels and keyboard support.
- Ensure alerts provide clear, concise, and actionable messaging.
- Position alerts in a predictable location to ensure users can find them easily.
- Consider how persistent the alert should be—does it need to stay on the screen until dismissed, or should it disappear automatically?
- If the aria-live is "assertive" the alert is read immediately
- If the aria-live is "polite" the alert is read when the user is idle
- Error messages should inform the user on how to fix them
- If the aria-live is "assertive" the alert is read immediately
- If the aria-live is "polite" the alert is read when the user is idle
- Error messages should inform the user on how to fix them
- Alerts should be visible when they are announced to a user.
- They should perform the same for users that are keyboard-only and users that are utilizing
a mouse.
- Example: an alert that notifies a user that the form they filled out is incomplete would be visible regardless of whether the "submit" action was done via mouse or navigated to using the keyboard
3.3.1 Error Identification A 3.3.3 Error Suggestion AA 4.1.3 Status Messages 1.4.13 Content on Hover or Focus AA