Your mobile landing page looks tidy until someone reaches the last form field. The keyboard opens. A consent banner is still on screen. The “Book a demo” bar, which looked modest in the design file, now sits exactly where the form's Submit button should be.
Moving the bar a few pixels is unlikely to fix that page. First decide what job the bar has. Then decide whether the page makes room for it or lets it sit over content. Finally, test the states that were missing from the design file: a long label, an open keyboard, an error message, the end of the page and another persistent control.
That is the practical answer to keeping mobile actions available without covering content. A docked bar sits against the bottom edge and can have page space reserved for it. A floating bar sits above the page, with content continuing behind it. If the action is needed throughout the journey, reserving space is a sensible starting point. If the control floats, its smaller footprint still needs a reason and a collision test. Barrava supports both placements; the published site decides how the rest of its interface behaves around them.
Decide which actions deserve to follow the visitor
Persistent means the control stays within reach as the person scrolls. It does not mean every campaign link deserves a place in it. On a narrow screen, each extra action takes space from the page and from the other actions.
Start with the visitor's task. On a product guide, Search and Contact might remain useful all the way down. On a demo booking form, a second “Book a demo” action may add little: the visitor is already doing that job. A permanent campaign offer might distract from completing the form.
Write one sentence for each proposed action: “Keep this visible because someone reading this page may need to ___ before they can ___.” If you cannot finish it with a real task, leave the action in the page or navigation. If you hide a lower-priority action on mobile, check that its destination remains easy to find elsewhere. Barrava has device visibility settings and an ordered module rail, but those settings cannot choose priorities for you.
This is an editorial decision as much as a layout decision. Shorter labels make the rail easier to fit, but “Go” is a poor substitute for “Book a demo”. Remove an action before stripping the words that tell people what it does. Barrava keeps visible modules in one contained line and allows some labels to wrap within their buttons; very long copy can still clip, so test the actual words you plan to publish.
Give the bar a clear layout contract
Ask the site owner and developer to choose one of two behaviours before launch:
| Placement | What happens to the page? | Good starting point | Main risk to test |
|---|---|---|---|
| Docked, with reserved space | The page leaves room beneath its last content so it can scroll clear of the bar. | Continuing navigation or several important actions. | The reserved height is too small after labels, device insets or page changes. |
| Floating, without reserved space | Content may pass behind the control. | A restrained action whose overlay is acceptable on this page. | A form button, focused link or consent choice is covered. |
Reserved space is simply the extra room at the bottom of the page. It should be based on the bar that actually renders, including any device-edge inset, rather than a guessed height from a mock-up. A phone with larger text or a two-line label may need more room. If the site already has bottom spacing for its own checkout or navigation, the two systems need one owner. Adding both amounts blindly creates a needless gap; replacing the site's spacing blindly can hide its control.
The safe area is the region a device keeps clear of its rounded corners, home indicator or other screen edges. CSS exposes a safe-area-inset-bottom value for layouts that need it (W3C CSS Environment Variables). Add that inset where it belongs, then check whether the measured bar height already contains it. Counting it in the bar and again in the page reserve leaves an odd blank strip.
Barrava's docked automatic spacing can measure its rendered shell and preserve a larger existing page-bottom padding. Floating mode clears Barrava's spacing override and intentionally overlays the page. Manual spacing is available for sites with a named layout target. These product behaviours are a useful starting point, but a live page with its own fixed controls still needs a joint layout review.
Work through a mobile form before approving the design
Take this illustrative page, not a customer result or a Barrava measurement. A campaign page has an eight-field demo form. The team wants Contact and Search in a mobile bar. The page also has a consent banner on first visit and a chat window when someone asks for help.
- Start with the real task. Someone halfway through the form is trying to finish it, not start another journey. Keep Contact available on the page; remove the duplicate persistent “Book a demo” link from this form route. Search can stay in site navigation if there is no strong reason to keep it under the form.
- Pick the layout behaviour. If the remaining bar still serves the wider site, try docked placement and let the form's Submit button and error messages scroll fully above it. Do not set a permanent bottom gap from a design screenshot; inspect the rendered bar with its final label and device inset.
- Open the awkward states. Show the first-visit consent banner. If it needs the bottom edge, decide which component yields or waits; raising
z-index(the page's layer-order setting) only chooses which thing covers the other. Open the site's existing chat and check its input and close control. In this example, chat and consent are separate site-owned controls. Test their actual behaviour together with the bar. - Complete the form on a phone. Focus the final field so the on-screen keyboard appears. Trigger a validation error and use the keyboard to move forwards and backwards. The error, input, Submit button and current focus must remain findable. If the bar crowds that state, reduce the action set, change the page's handling while editing or revise placement. Recheck after the keyboard closes.
- Inspect the result, not only the click. Can the person read the error and submit? Can they return to the form after opening chat? Does the last footer link scroll clear? A higher bar click count would not rescue a broken booking form.
That walkthrough tells the team what to change. It also shows why the answer may be “no persistent control on this particular route”. A well-placed action in the page can beat a permanent control that competes with the task already under way.
Make focused content visible, not merely clickable
A person using a keyboard or a switch device can move through the page without tapping it. Focus is the item that would respond to the next key press. If the focus moves to a link behind a sticky footer, the page may still be operable in theory while the person cannot see where they are.
WCAG 2.2 Focus Not Obscured (Minimum) says an item receiving keyboard focus must not be entirely hidden by content the site creates. Aim higher than that floor: keep the whole item and its focus indicator visible when practical. Test the bar and the page around it. Use Tab and Shift+Tab from the header through the form, validation links and footer while the bar is visible. Test anchor links and “skip to content” too; they can scroll to a target that lands behind a persistent edge.
Page-bottom reserve helps the final content, but anchor and scripted scrolling can still place a target badly. A developer may need scroll-padding on the right scroll container or an equivalent target offset; the CSS scroll-padding specification describes the inset. The release question is simpler: after you follow an in-page link, can you see the destination heading and operate the next control?
Buttons also need room to use accurately. WCAG 2.2 Target Size (Minimum) sets a 24 × 24 CSS-pixel floor with specific exceptions, including sufficient spacing around smaller targets. A CSS pixel is the browser's layout unit, rather than a physical screen dot. The WCAG number is a compliance threshold, not a layout ambition. Barrava's design guidance aims for 44px touch targets where the layout allows. Test neighbouring actions with your thumb, larger text and the narrowest supported screen before declaring the rail comfortable.
Test the page when the screen stops behaving like a mock-up
A responsive preview helps find obvious problems, but it is not the whole release test. Browser controls appear and disappear; the screen rotates; text becomes larger; and the on-screen keyboard takes away visible room. WCAG Reflow checks whether content can rearrange to fit a 320 CSS-pixel width, with limited exceptions for content that genuinely needs two-dimensional layout. A bar that forces sideways scrolling or clips all its labels needs another pass.
Use this short release route on at least one real mobile browser as well as responsive tooling:
- Visit the top, middle and final screen of the real page. Reach the last link, form control and footer with the bar visible.
- Repeat at a narrow width, in landscape, and with larger text. Check that labels and action targets remain understandable.
- Tab through the page forwards and backwards. Follow an anchor link and a skip link. Record any focused item the bar hides.
- Open the keyboard in a field near the bottom. Trigger an error and submit or correct the form.
- Repeat with consent, chat and any campaign prompt in the combinations a visitor can really see. Check each close and return path.
Give each failure a page URL, device/browser, visible state and owner. “Looks fine on mobile” cannot tell a developer which collision to fix.
The original Barrava SPACE check is a useful way to sign off that route: Space is the bar's measured footprint and reserve; Priority is the action set; Areas covers safe insets and the end of the page; Controls covers labels, targets and visible focus; Edge cases covers the keyboard, orientation, validation and other overlays. Mark each part pass, named exception or fix needed. It keeps a visual review from becoming the only approval.
Where Barrava fits
Barrava gives a team an ordered toolbar with docked and floating variants, module visibility settings, and configurable actions. In docked mode, its automatic page-spacing path uses the rendered bar height where available. That makes the choice between reserving room and overlaying content explicit in the product.
It does not promise that every host page, consent banner or chat provider will fit around the bar. The website team still owns the full journey and must check the real page. If you are planning a bar, try it first on your most awkward mobile page, not your emptiest one. The website toolbar versus sticky bar versus pop-up comparison helps with the broader pattern choice; this guide is for making the chosen placement work on a phone.
Next step: Configure a small action set in Barrava, preview it on the form or page that matters most, and run the five release steps before publishing it to visitors.
