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 group 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 Readtime Scheme dropdown Scheme toggle Select Site status Skeleton Skip link Spinner Statistic Subnavigation Surface Switch Table Tabs Tag Tile Timestamp Tooltip Video embed How to useProject FeltColor PalettesCustomizingDevelopers All PatternsAccordionAlertCall to ActionCardFilterFormLink with iconLogo wallSearch barSticky bannerSticky cardTabsTagTile AI design principlesLegal requirementsTransparency noticesIconographyColorChatbot avatarsAnimation All Personalization PatternsAnnouncement FundamentalsColorAccessibility toolsAssistive technologiesCI/CDContentContributorsDesignDevelopmentManual testingResourcesScreen readers Design/code status Release notes Get support

Footer Since v1.0.0

OverviewStyleGuidelinesCodeAccessibilityDemos
Landmark rolesKeyboard interactionsFocus orderARIA Authoring Practices Guide (APG)Web Content Accessibility GuidelinesLandmark rolesKeyboard interactionsFocus orderARIA Authoring Practices Guide (APG)Web Content Accessibility Guidelines

Landmark roles

<rh-footer> and <rh-footer-universal> (when used outside of <rh-footer>) already include a contentinfo landmark role and therefore do not need to be wrapped in a native <footer> element. This contentinfo role is applied automatically through the ElementInternals API.

If a <rh-footer> or <rh-footer-universal> is placed inside an existing <footer> element, the custom element will not receive the contentinfo role. In those cases, implementors should remove the surrounding <footer> element and rely on the role applied directly to the custom element via ElementInternals.

Keyboard interactions

The footer includes many different interactive elements that can be navigated with a keyboard.

A footer showing light blue focus rings and dotted underlines on links in a dark color scheme footer
Key Result
Tab Moves the focus to the next interactive element
Shift+Tab Moves the focus to the previous interactive element
Space Opens the language selector menu
Up arrow / Down arrow Moves the focus to each language
Enter Selects a language and enables it on the page
Esc Closes the language selector menu

Focus order

A logical focus order helps keyboard users operate our websites. Elements need to receive focus in an order that preserves meaning, therefore the focus order should make sense and not jump around randomly. The focus moves across regions of a footer from left to right and top to bottom.

A footer showing groups of focus indicators in different regions with annotation numbers

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

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.

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

Edit this page on GitHub
© 2026 Red Hat Deploys by Netlify