Skip to main content Home About the Design SystemRoadmap OverviewDesignersDevelopers OverviewColorGridIconographyInteractionsSpacingTypography Overview Global colorBox shadowTypographyBorderOpacitySpaceLengthIconBreakpointsMedia queries All elements Accordion Alert Announcement Audio player Avatar Back to top Badge Blockquote Breadcrumb Button Card Chip Code block Call to action Dialog Disclosure Footer Health index Icon Jump links Menu dropdown Navigation link Navigation (primary) Navigation (secondary) Navigation (vertical) Pagination PopoverPlanned Progress stepper Scheme toggle Site status Skeleton Skip link Spinner Statistic Subnavigation Surface Switch Table Tabs Tag Tile Timestamp Tooltip Video embed OverviewColor PalettesCustomizingDevelopers All PatternsAccordionAlertCall to ActionCardFilterFormLink with iconLogo wallSearch barSticky bannerSticky cardTabsTagTile All Personalization PatternsAnnouncement FundamentalsAccessibility toolsAssistive technologiesCI/CDContentContributorsDesignDevelopmentManual testingResourcesScreen readers Design/code status Release notes Get support

Alert

OverviewStyleGuidelinesCodeAccessibilityDemos
Keyboard interactionsFocus orderToastsARIA Authoring Practices Guide (APG)Web Content Accessibility GuidelinesKeyboard interactionsFocus orderToastsARIA Authoring Practices Guide (APG)Web Content Accessibility Guidelines

Keyboard interactions

A user should have the ability to navigate to and interact with alerts using their keyboard.

Example of the keyboard navigation tab stops on both inline and toast variant alerts
Key Result
Tab Moves focus to the next interactive element (e.g., from the close button to the first action button in the alert)
Shift + Tab Moves focus to the previous interactive element (e.g., from the first action button in the alert back to the close button)
Enter Triggers the close button, an action button, or link

Focus order

A logical focus order helps users understand and operate our websites and products. Elements need to receive focus in an order that preserves meaning. Therefore the focus order should make sense and not jump around randomly.

Focus goes to action buttons and to the close button last

Toasts

Accessibility considerations

There are accessibility considerations to keep in mind when using toasts. See our toast pattern accessibility guidelines for more information.

Toasts created with RhAlert.toast() are not the same as inline alerts in how assistive technology exposes them.

The toast container uses role="status" and aria-live="polite", so updates are announced as polite status messages, not as an interrupting role="alert". Inline alerts use role="alert" on the alert surface. Do not assume a toast has the same urgency or immediacy as an inline alert.

Toasts render inside a single "toaster" region appended to document.body, not next to the control that triggered them. That separation affects reading order and discovery (WCAG 1.3.2 Meaningful Sequence). Design mitigations (when to use a toast, persistence, redundant in-context feedback) are covered at toast Alert pattern — Accessibility.

RhAlert.toast() does not move keyboard focus into the toast when it appears. Many screen reader users will still hear the announcement; sighted keyboard users must Tab to the toast to reach the dismiss control and any actions.

ARIA Authoring Practices Guide (APG)

Learn to use the accessibility semantics defined by the Accessible Rich Internet Application (ARIA) specification to create accessible web experiences.

View APG resources

Web Content Accessibility Guidelines

Understanding documents provide detailed explanations for Web Content Accessibility Guidelines (WCAG) guidelines and success criteria.

Automated testing

Some of our elements may receive errors or warnings that are false positives from automated testing tools. If you are experiencing some of these issues, please read our update on false positives in automated tools.
Edit this page on GitHub
© 2026 Red Hat Deploys by Netlify