Persistent mobile actions without covering content

Start with a reserve-or-overlay decision

There are two honest placement models. A docked action layer belongs to the page layout and needs reserved space; a floating layer sits above the layout and may obscure what passes beneath it.

Choose reserve space when the action set is part of the site's continuing navigation or task flow. The page should remain complete when the bar is present: its final link, form control, error message and footer content must all be able to scroll above the persistent layer. This is usually the safer default for a full-width bottom action bar.

Choose overlay only when the smaller footprint and temporary emphasis justify covering part of the viewport. A floating action button can be reasonable when it occupies a restrained area, has a clear priority and does not sit over essential controls. Overlay is a behaviour, not a visual style; rounded corners do not stop a component from obscuring content.

Measure the rendered control instead of guessing its height

Reserve space from the control that actually renders, not only from a design token or desktop mock-up. Labels, safe areas and responsive states can change the required height.

A fixed padding value can work until a label wraps, text is enlarged, a validation state appears or a different device adds a bottom inset. Where the implementation allows it, measure the rendered shell and update the reserve after relevant size, orientation and configuration changes. Keep a tested fallback for the interval before measurement is available.

Preserve the page's existing bottom padding. The useful reserve is normally the larger of the existing spacing and the space required by the persistent control, not a blind replacement. If the site already reserves room for a checkout panel, accessibility control or native app shell, ownership needs to be explicit before another component changes the same property.

Keep the end of the page and every focus target visible

A persistent bar has failed its layout job if the last actionable item cannot move fully above it or a keyboard user can focus a control that remains hidden behind it.

WCAG 2.2 Focus Not Obscured (Minimum) requires a focused user-interface component not to be entirely hidden by author-created content. Test keyboard movement forwards and backwards through links, fields, validation summaries, accordions and footer controls. A visible focus ring on the bar does not prove that page content behind it is operable.

Reserve spacing solves much of the geometry, but anchor links and scripted scrolling need separate attention. The CSS scroll-padding model defines an inset from the scrollport edge for its optimal viewing region. Depending on the scrolling container and navigation behaviour, scroll-padding or target scroll-margin can help a heading or focused control settle clear of persistent UI. Test the actual browser behaviour rather than adding both indiscriminately.

Account for safe areas and changing browser chrome

Mobile screen height is not one stable rectangle. Device cut-outs, browser controls and the on-screen keyboard can all change the area that is genuinely visible.

CSS environment variables expose safe-area insets such as safe-area-inset-bottom. Use that inset to keep essential controls away from the device edge, then decide whether it is already included in the measured bar height. Adding the same inset to the bar and again to the page reserve can create an unnecessary empty strip.

CSS also distinguishes large, small and dynamic viewport units. Large units assume retractable browser interface is hidden; small units assume it is shown; dynamic units respond as that interface changes. Those definitions are useful when a mobile panel is sized to the viewport, but they do not remove the need to test a persistent bar while the address bar expands and retracts.

The on-screen keyboard is a separate state. The Visual Viewport API documentation notes that a keyboard can shrink the visual viewport without changing the layout viewport. A control fixed against the layout viewport may therefore collide with the keyboard or the field being edited. Test whether the bar should move, collapse or temporarily yield while input is active; do not assume one behaviour fits every form.

Adapt the action set before shrinking the controls

When space tightens, reduce and prioritise the action set before making every target, icon and label harder to use.

Start with the visitor's current job. Keep the few actions that remain valuable across the mobile journey, move secondary routes back into the page or main menu, and remove duplicates already supplied by the browser or site navigation. Device visibility rules can be legitimate when they preserve the same outcome through another route; hiding an action without an equivalent path is a loss of functionality.

WCAG 2.2 Target Size (Minimum) sets a 24 by 24 CSS pixel threshold with specific exceptions, including sufficient spacing around undersized targets. Barra's design system aims for comfortably clickable controls and suggests 44px touch targets where the layout allows. Treat the accessibility criterion as a floor with conditions, not a design target to squeeze towards.

Keep labels concise, but do not remove the accessible name when visible text is truncated. Test long words, translated labels and larger text. WCAG Reflow uses a 320 CSS pixel width for vertically scrolling content, with exceptions for content that genuinely requires two-dimensional layout. A primary mobile action row usually needs a priority decision rather than horizontal page scrolling.

• Protect one clear primary action before preserving decorative symmetry.
• Keep icon-only controls familiar, named and distinguishable without colour alone.
• Use truncation as a controlled fallback, not as permission for unclear labels.
• Verify that any mobile-hidden action still has an understandable route elsewhere.

Control competing edge elements as one system

A mobile action bar cannot be reviewed in isolation when consent controls, chat, feedback, browser UI and campaign prompts occupy the same edges.

Create an inventory of every production element that can become fixed, sticky or floating. Record its edge, dimensions, trigger, priority, dismissal behaviour, persistence and owner. Then define collision rules: which element moves, yields, collapses or waits when another is open. Z-index alone only decides which problem is visible on top.

Google Search Central recommends restrained banners rather than promotional interstitials that obstruct content. That guidance is not a blanket approval for stacking several small banners. The combined occupied area, timing and access to the underlying content determine whether the result remains usable.

Test the states that reduce usable mobile height

A clean 390px design frame is only one state. Release testing should cover the moments when the visible area becomes smaller or content becomes taller.

Use at least one real mobile browser as well as responsive tooling. Test portrait and landscape, browser controls shown and hidden, text enlargement, page zoom where supported, and the smallest supported width. Open the on-screen keyboard in fields near the bottom and trigger both short and long validation messages.

Repeat the route with consent, chat, feedback and campaign components in the combinations visitors can actually encounter. Navigate directly to an anchor, use the browser's find function, tab through the page, follow a skip link and return from browser history. Check the first screen, the middle of a long page and the final page action.

• No final content or control remains trapped beneath persistent UI.
• Keyboard focus is visible when moving in both directions.
• Touch targets remain usable at narrow widths and larger text sizes.
• Safe-area and reserve spacing are not counted twice.
• The on-screen keyboard does not strand the active field or action.

Run the SPACE mobile-action check before release

SPACE is a five-part Barra review for persistent mobile controls: Space, Priority, Areas, Controls and Edge cases. It turns a visual approval into a repeatable release decision.

Space asks whether the component reserves layout room or overlays the page, who owns that behaviour and how the required height is measured. Priority asks whether every persistent action earns scarce mobile space and whether a lower-priority route remains available elsewhere.

Areas covers device safe insets, browser chrome and the end of the page. Controls covers target size, labels, focus visibility, dismissal and restoration. Edge cases covers orientation, zoom, keyboard, validation, anchors and competing fixed elements. Record a pass, a named exception or a blocking defect for each part.

1. Space: name reserve or overlay behaviour and verify the measured footprint.
2. Priority: keep only actions that deserve persistent mobile visibility.
3. Areas: account for safe insets, browser interface and page endings.
4. Controls: verify touch, keyboard, labels, focus and dismissal.
5. Edge cases: test orientation, zoom, keyboard, anchors and collisions.

How Barra makes reserve or overlay an explicit choice

Barra's current runtime treats docked reserve spacing and floating overlay as separate behaviours rather than hoping one fixed position works for every page.

For a docked bar, Barra supports automatic, manual or off spacing. The default automatic path can reserve space on the document body, measures the rendered shell when available and preserves a larger existing bottom padding. Manual mode supports a named target and explicit reserve where the page structure needs different ownership. Safe-area contribution is added where it is not already represented by the measured shell.

For a floating bar, Barra intentionally clears its page-spacing override. That makes overlay a visible product decision rather than a hidden side effect. The responsive action rail keeps enabled modules on one contained line and can truncate CTA labels at narrow widths; teams still need to prioritise actions and confirm the resulting labels remain understandable.

This implementation is first-party proof of the reserve-or-overlay model, not evidence that every site should use the same configuration. Barra does not replace a consent platform, chat provider, analytics product or legal review. Each installation needs its own SPACE check with the real page, real competing elements and supported mobile browsers.

Further reading

• Explore Barra's website toolbar — See the current configurable website action layer while the homepage retains website-toolbar commercial ownership.
• Audit the modern website clutter problem — Understand why individually useful edge controls can combine into one fragmented mobile journey.
• Learn why poor navigation affects conversion journeys — Connect persistent actions to wider information scent and route clarity without turning this guide into a navigation definition.
• Book a Barra demo — Review reserve and overlay behaviour against a real website layout and its competing controls.

Sources

1. Understanding Focus Not Obscured (Minimum) — W3C Web Accessibility Initiative
2. Understanding Target Size (Minimum) — W3C Web Accessibility Initiative
3. Understanding Reflow — W3C Web Accessibility Initiative
4. CSS Environment Variables Module Level 1 — W3C
5. CSS Values and Units Module Level 4 — W3C
6. CSS Scroll Snap Module Level 1 — W3C
7. VisualViewport — MDN Web Docs
8. Avoid intrusive interstitials and dialogs — Google Search Central (2025-12-10)
9. The modern website clutter problem — Barra (2026-03-11)