A practical accessibility checklist for persistent website controls, covering visible focus, target size, content overlap, labels and real responsive states.
Quick answer
Accessible persistent controls keep keyboard focus visible, provide usable targets and labels, avoid trapping or covering page content, and remain operable when the viewport, text size or competing interface changes.
Sticky bars and floating actions can make an important route easier to reach. They can also create a new obstruction that follows people through the page. The difference is not the visual pattern alone; it is how the control behaves across input methods and page states.
This checklist turns a polished screenshot into a release test. It is not an accessibility certification. Use it alongside the applicable WCAG requirements, assistive-technology testing and the real content around the control.
Keep focused controls visible
A keyboard user must be able to see the control that currently has focus, including page controls behind or beside persistent interface.
WCAG 2.2 added Focus Not Obscured (Minimum): when a user-interface component receives keyboard focus, author-created content must not entirely hide it. A sticky footer, floating panel or expanded action tray can cause exactly that failure.
Tab forwards and backwards through the page with the persistent control open, collapsed and expanded. Include form errors, skip links, anchored headings, consent controls and the final links in the footer. A visible focus ring inside the toolbar does not prove that the rest of the page remains visible.
- Test focus before, inside and after the persistent control.
- Check both collapsed and expanded states.
- Retest when validation messages or cookie controls appear.
Make targets comfortably operable
Size and spacing need to support accurate activation without forcing people to aim between crowded actions.
WCAG 2.2 Target Size (Minimum) sets a 24 by 24 CSS pixel minimum with defined exceptions, including sufficient spacing. Treat that as a conformance floor, not a reason to compress a busy action rail.
Barra's design guidance aims for 44px touch targets where layout allows. The practical test is whether actions remain distinguishable with larger text, on a narrow screen and when a nearby control is also available.
- Do not rely on colour alone to distinguish actions.
- Keep the accessible name when visible text is shortened.
- Remove lower-priority actions before shrinking every target.
Choose reserve space or overlay deliberately
Persistent interface should either reserve layout space or accept and test the consequences of overlaying the page.
Barra's docked mode can reserve the measured rendered height while preserving a larger existing bottom padding. Its floating mode intentionally overlays content and clears that reserve. This makes the placement trade-off explicit rather than hiding it behind styling.
For either model, test the last paragraph, final action, browser zoom, safe areas, orientation changes and the on-screen keyboard. Do not count safe-area space twice, and do not assume a fixed desktop height describes the mobile component.
Review the combined edge state
A control can pass on its own and still fail when chat, consent, campaigns or browser interface occupy the same edge.
List every fixed, sticky and floating element that can appear on the target journey. Decide which element yields, moves, collapses or waits. Raising z-index only chooses which obstruction sits on top.
Finish with real-device testing and a named owner for each exception. Persistent controls remain part of the page, so accessibility review must follow them whenever their actions, labels, dimensions or surrounding interface change.
Further reading
Sources
- What's New in WCAG 2.2 — W3C Web Accessibility Initiative
- Understanding Success Criterion 2.5.8: Target Size (Minimum) — W3C Web Accessibility Initiative
- Avoid intrusive interstitials and dialogs — Google Search Central
Frequently asked questions
Does passing this checklist prove WCAG conformance?
No. It is a focused release aid for persistent controls, not a complete WCAG audit or certification.
