Sticky footer

Overview

A sticky footer pins the page's primary commit action to the bottom of the viewport so a long scroll never separates the user from “Save”. The bar lives above the page content, takes its own background, and uses a 1 px top border or a subtle shadow to mark its edge.

Types

Two layout variants, picked by the job. Fixed is the structural case — the primary path on a long form. Floating is reserved for one specific job: row-selection bulk actions on a table. The bar appears the moment the user checks a row, holds the selection summary and the actions that operate on it, and disappears the moment the selection clears. Don't reach for the floating variant for unsaved-draft alerts, announcements, or any other transient surface — those need a different pattern.

Anatomy

Four named parts. The container carries the surface and the edge treatment; everything inside is two slot regions split by justify-between. The inner row honours the page's max-width — same gutters as the rest of the page so actions land under the form column they belong to.

Max-width

Three inner widths cover almost every page in the product. The container is always edge-to-edge; the inner row honours the chosen width. Pick the value that matches the page's content column — don't set a different width for the bar than the form above it. The Save button has to sit directly under the field it commits; a mismatch between the content column and the action bar leaves the eye chasing it across the page.

• Full — actions stretch to the page edges minus the gutter. Use when the form fills the viewport (settings, bulk edit).
• 7xl (1280 px) — matches the standard product page content column. Default for most flows.
• 4xl (896 px)— narrow forms (account, single-task wizards). Actions align with the form's reading column.

Mobile

On phones the bar still pins to the bottom of the viewport, but the interior layout adapts. Fixed keeps the left/right split with both buttons at full 48 px height — thumb reach over visual symmetry. Floating stacks the actions on top of the summary line so the buttons claim the tap-priority row.

Behavior

• 01Use position: sticky, not fixed. Sticky positions the bar relative to its scroll container so the footer sits below content when the page is short, and pins to the viewport bottom when the page scrolls. Fixed positioning works but covers content on short pages.
• 02Reserve scroll padding. Add padding-bottom equal to the footer's height on the page's scroll container so the last form field can scroll above the bar instead of getting stuck behind it.
• 03Don't animate the bar in and out on scroll. The bar is either present or absent — never sliding away to recover screen real estate. Hide-on-scroll patterns confuse users about where the action lives.
• 04Floating bars enter and exit with their context. When the user selects rows, the bar slides up from the bottom in 200 ms; when the selection clears, it slides back down. No dismiss button — the trigger handles its own lifecycle.
• 05Honour reduced-motion. The 200 ms enter/exit on floating bars is a fade + small translateY. Cut the translate when prefers-reduced-motion is set; keep the fade.

Accessibility

• Landmark: wrap the bar in a <footer> with an accessible name (aria-label="Page actions" or similar). Screen readers can jump to it as a landmark.
• Tab order:the bar comes after the page content in DOM order so keyboard users naturally land on the commit action after stepping through the form. Don't hoist it to the top of the DOM for visual reasons.
• Disabled commit:when the action isn't ready (form invalid, nothing selected), use aria-disabled="true" so the button stays focusable and screen readers announce the state. Pair with helper text explaining what's missing.
• Floating bars announce themselves: when a bulk selection appears, surface the bar via an aria-live="polite" region with the count and the available actions. Don't rely on the visual entrance alone.
• Focus trap:when the bar opens a confirmation (e.g., destructive primary), trap focus inside the dialog until it's resolved. The bar itself doesn't trap focus — the page is still navigable.

Code

The StickyFooter ships from @flatpay-dk/ui. It owns the layout (sticky position, surface, max-width) and composition (slot grammar). The actual buttons come from the Button component.

import { StickyFooter, Button } from "@flatpay-dk/ui";

// Default — fixed bar, full width, cancel + primary
<StickyFooter>
  <Button variant="tertiary" onClick={cancel}>Cancel</Button>
  <Button variant="primary" onClick={save}>Save changes</Button>
</StickyFooter>

// Match the bar's maxWidth to the page's content column.
// If the form is wrapped in max-w-4xl, the bar is maxWidth="4xl".
<main className="mx-auto w-full max-w-4xl px-6">
  {/* …form fields… */}
</main>
<StickyFooter maxWidth="4xl">
  <Button variant="tertiary">Cancel</Button>
  <Button variant="primary">Continue</Button>
</StickyFooter>

// Floating — table bulk actions only. Mount the bar when a row is
// selected, unmount when the selection clears. Don't leave it
// mounted with zero rows checked.
{selected.size > 0 && (
  <StickyFooter type="floating" aria-label="Bulk actions">
    <p>{selected.size} products selected</p>
    <div className="flex items-center gap-3">
      <Button variant="secondary" onClick={() => exportRows(selected)}>
        Export
      </Button>
      <Button variant="primary" onClick={() => archive(selected)}>
        Archive
      </Button>
    </div>
  </StickyFooter>
)}

// Disabled commit while the form is invalid
<StickyFooter>
  <Button variant="tertiary" onClick={cancel}>Cancel</Button>
  <Button
    variant="primary"
    onClick={save}
    disabled={!form.isValid}
    aria-disabled={!form.isValid}
  >
    Save changes
  </Button>
</StickyFooter>

Best practices

The bar holds the commit step. Treat it like the most important surface on the page, because for most users that's exactly what it is.

Props

Related