generic behavior · Structural containers and states
Sticky & Fixed
Two positioning behaviors that keep an element visible during scroll — sticky anchors within a container, fixed anchors relative to the viewport.
Decisive boundary
Sticky is scoped to a parent container; fixed applies to the entire viewport. Choose sticky when the element should not outlive its section.
Definition and intent
What is a Sticky & Fixed UI pattern?
Use the behavior, not the silhouette
Two positioning behaviors that keep an element visible during scroll — sticky anchors within a container, fixed anchors relative to the viewport. The term is used here as a generic behavior label that still needs a more specific semantic structure around it. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Keep essential navigation, information, or actions accessible while the user scrolls. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Sticky & Fixed, the boundary is: Sticky is scoped to a parent container; fixed applies to the entire viewport. Choose sticky when the element should not outlive its section.
Do not implement it as Fixed positioning for a full-height sidebar that should scroll with the page, and sticky when the element must outlast its container boundary. If those requirements describe the real task better, use the related pattern page or the full Structural containers and states comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Keep essential navigation, information, or actions accessible while the user scrolls.
Define opening and closing
Controlled by the user's scroll position, not a direct action. Passes when the container scrolls out of view (sticky) or when the page is navigated (fixed).
Specify access behavior
Sticky and fixed elements participate in normal document focus order; fixed overlays must not trap focus. No custom keyboard model; controls within the element follow normal tab order.
Reject the near miss
Fixed positioning for a full-height sidebar that should scroll with the page, and sticky when the element must outlast its container boundary.
Behavior contract
What must survive the build
- trigger
- Controlled by the user's scroll position, not a direct action.
- dismissal
- Passes when the container scrolls out of view (sticky) or when the page is navigated (fixed).
- modality
- Non-modal persistent positioning behavior.
- focus
- Sticky and fixed elements participate in normal document focus order; fixed overlays must not trap focus.
- keyboard
- No custom keyboard model; controls within the element follow normal tab order.
- interactive
- May contain any interactive content appropriate for a persistent header, toolbar, or feedback button.
- persistence
- Persists while the scroll condition or viewport remains.
- placement
- Sticky: inside a container, toggles between static and fixed at a scroll threshold. Fixed: relative to the viewport at a configured edge.
- mobile
- Sticky headers must not cover so much of the viewport that content becomes unusable; fixed positioning may cause accessibility issues on small screens.
Failure modes
Common wrong builds
- Using fixed positioning for critical mobile navigation that hides content.
- Forgetting that sticky requires a threshold and a container overflow context.
- Omitting a close or reveal path for fixed overlays that cover interactive content.
Observable checks
Verify the result
- Sticky triggers at the correct scroll threshold.
- Fixed elements do not obscure interactive content.
- Mobile viewport shows enough content around the positioned element.
- The positioning type matches the user task.
- Keyboard focus is not trapped by a fixed overlay.
Coding-agent handoff
Implementation brief template
Pattern: Sticky & Fixed Purpose: Keep essential navigation, information, or actions accessible while the user scrolls. Trigger: Controlled by the user's scroll position, not a direct action. Dismissal behavior: Passes when the container scrolls out of view (sticky) or when the page is navigated (fixed). Modality: Non-modal persistent positioning behavior. Focus behavior: Sticky and fixed elements participate in normal document focus order; fixed overlays must not trap focus. Keyboard behavior: No custom keyboard model; controls within the element follow normal tab order. Interactive content: May contain any interactive content appropriate for a persistent header, toolbar, or feedback button. Placement: Sticky: inside a container, toggles between static and fixed at a scroll threshold. Fixed: relative to the viewport at a configured edge. Mobile behavior: Sticky headers must not cover so much of the viewport that content becomes unusable; fixed positioning may cause accessibility issues on small screens. Do not implement as: Fixed positioning for a full-height sidebar that should scroll with the page, and sticky when the element must outlast its container boundary. Acceptance checks: - Sticky triggers at the correct scroll threshold. - Fixed elements do not obscure interactive content. - Mobile viewport shows enough content around the positioned element. - The positioning type matches the user task. - Keyboard focus is not trapped by a fixed overlay.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Sticky & Fixed UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Sticky & Fixed in web UI?
Two positioning behaviors that keep an element visible during scroll — sticky anchors within a container, fixed anchors relative to the viewport. In this reference set it is a generic behavior label that still needs a more specific semantic structure around it.
When should I use a Sticky & Fixed?
Keep essential navigation, information, or actions accessible while the user scrolls. The decisive boundary to confirm is this: Sticky is scoped to a parent container; fixed applies to the entire viewport. Choose sticky when the element should not outlive its section.
What keyboard and focus behavior does a Sticky & Fixed need?
No custom keyboard model; controls within the element follow normal tab order. Sticky and fixed elements participate in normal document focus order; fixed overlays must not trap focus. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Sticky & Fixed behave on mobile?
Sticky headers must not cover so much of the viewport that content becomes unusable; fixed positioning may cause accessibility issues on small screens. Its modality is a separate requirement: Non-modal persistent positioning behavior.
How do I verify a Sticky & Fixed implementation?
Start with observable checks: Sticky triggers at the correct scroll threshold. Fixed elements do not obscure interactive content. Mobile viewport shows enough content around the positioned element. Then verify the remaining checks and compare the result with the linked source guidance.