Skip to content

Footer

C-51 · Components · Navigation

All elements · Footer on the Components page

Last checked 2026-10-22 · Awaiting approval · Accessibility tests

Copies the bun run a11y:approve command for Footer.

Guidance

When to use

  • End every page of the app with the product name and version, so users can quote it to support.
  • Link the accessibility statement from every page, first among the links; federal sites and many state rules expect it there (Section 508, ADA Title II).
  • Put privacy, terms of use and the support contact beside it, and the copyright line under them.
  • Use the compact variant in the App shell's footer slot (.qf-container > .qf-footer), where it sits on the chrome under the content.

When to consider something else

  • When the bar shows live facts about the open document (page, word count) or holds view and zoom controls, use StatusBar. See StatusBar.
  • When the links are destinations users visit often (Help, Settings), put them in the shell's utility strip or the Side navigation. See App shell.
  • When a message about the app's state must reach the user (maintenance tonight, offline), use a Banner; nobody reads the footer for news. See Banner.

Usability

Do
  • Keep it to one or two lines; the app's footer is not a site map.
  • Show the full version and build in the default variant; the compact variant can drop the build.
  • Name the accessibility link "Accessibility statement" (or "Accessibility" when compact), not "508".
  • Keep the same links in the same order on every page.
  • Open the statement and policies in the same tab unless the user is mid-task, then warn that a link opens a new tab.
Don’t
  • Don't put live status (saving, connection, counts) in the footer; that is StatusBar's job and the footer is not announced.
  • Don't hide the footer behind a scroll inside the content; in the shell it stays in its slot.
  • Don't use it for primary actions or navigation the user needs to finish a task.
  • Don't shrink link text below the extra-small size or the links below 24px tall.

Accessibility

Keyboard

Footer keyboard
Keys Action
Tab / Shift+Tab Moves through the footer links in order, after the page content.
Enter Follows the focused link.

Roles and names

  • The block is a footer outside main (in the shell, the last child of .qf-container), so it is the page's contentinfo landmark; inside main, article or section it is not a landmark.
  • The links are a nav with an aria-label such as "Legal and support" holding a ul, so screen readers announce how many there are.
  • The product name and version are plain text in a p; the copyright line is a p.
  • There is one contentinfo per page; a dialog or window does not get its own footer landmark.

Focus

  • Links show the shared focus ring; in the shell slot, on the chrome, the ring is the chrome's white ring.
  • Nothing in the footer takes focus on its own or moves it.

Other requirements

  • Links are underlined and in the link color: 5.29:1 on the footer's sunken surface (9.23:1 in dark); in the shell slot they are white on the chrome, 9.44:1. Not color alone (1.4.1).
  • Each link is at least 24px tall (--qf-footer-target), meeting 2.5.8.
  • The parts wrap onto more lines at narrow widths and 400% zoom (1.4.10).
  • The accessibility statement link is the same on every page, in the same place (3.2.3, 3.2.6 Consistent Help when it carries the support contact).

Test your implementation too. This guidance covers the element as specified here. How a screen composes it (labels, order, announcements) still needs its own keyboard and screen reader check.

Accessibility tests

WCAG 2.2 AA · Passed

Passed the gate (run 358b316 on 2026-10-22): no finding in any theme. Awaiting a person’s approval of the checklist below.

Footer test checklist
Area Automated A person checks
General Passed Color is never the only cue, text alternatives say the same thing as the graphic, and the element reads the same in the light and the dark theme.
Zoom Passed At 200% zoom, at 320 CSS pixels wide and with the WCAG text-spacing overrides, nothing is lost, clipped or overlapping.
Keyboard Passed Every row of the Keyboard table works, focus is always visible and never trapped, and the tab order follows the reading order. (2 rows)
Screen reader Passed With NVDA or JAWS on Windows and VoiceOver on macOS, names, roles and states are announced as Roles and names says, and changes are announced once. (4 items)

Approving. When the checklist passes on the checked run, record it with bun run a11y:approve -- footer --by "Your name" and commit a11y/approvals.json with the rebuilt pages. All test status

Package

Consumers link one stylesheet, css/classic/index.css, which includes every element. The files below are where this element is defined.

Footer package
Source css/classic/components/footer.css
Specimens also use App shell · Box · Card · Chip · Icon · SideNavigation · Table · Text · Toolbar
Sprites sprites/icons.svg
React Not yet available: the React binding has not started.

Latest updates

Footer latest updates
Date Version Breaking Description
2026-10-20 0.1 No Footer (C-51): the app's page footer (footer.qf-footer, the contentinfo landmark): __product (__name, __version), a nav.__links of the accessibility statement, privacy, terms and support (24px targets), and the __legal copyright line; data-variant="compact" puts it on one line (components/footer.css). The App shell gains an optional footer slot, .qf-container > .qf-footer, on the chrome under the content; shells without one are laid out as before

All release notes