Prevent A Page From Scrolling While A Dialog Is Open

The Scroll Lock Problem

When you open a modal dialog on a webpage, users can still scroll the background content by swiping, using the mouse wheel, or pressing arrow keys. This creates a confusing and frustrating user experience where the intended focus on the dialog is interrupted by unexpected page movement.

Preventing page scrolling while a dialog is open is a fundamental aspect of creating polished, user-centered interfaces. Without scroll locking, users may lose their place in lengthy articles or product listings, creating friction that can push them away from completing desired actions. From a user-centered design perspective, scroll lock serves multiple important functions: it prevents accidental navigation away from the dialog context, maintains the user's scroll position in the underlying content, and creates a clear visual and behavioral separation between modal and page content. This subtle detail signals to users that the dialog represents a focused interaction mode where the rest of the page becomes temporarily inert.

The challenge of scroll locking has existed since modals became a standard UI pattern. Early solutions required JavaScript event listeners that could be fragile and inconsistently implemented across browsers. Modern CSS provides elegant, performant alternatives that handle this common interaction pattern with minimal code and maximum reliability, aligning with best practices in professional web development.

Understanding the Scroll Lock Problem

Why Background Scrolling Happens

When a dialog element opens using native <dialog> or a custom modal component, it doesn't automatically prevent scrolling on the underlying page. The browser continues to process scroll events on the document body, allowing users to inadvertently navigate away from their intended position. This becomes particularly problematic on touch devices where swiping gestures can easily scroll the background behind a modal overlay.

The underlying issue stems from how browsers handle scroll propagation and the document's scrollable area. Even when a dialog is displayed with a backdrop overlay, the body element remains scrollable. Users expect that opening a dialog creates a focused interaction mode where the rest of the page becomes temporarily inert. When this expectation isn't met, it signals a breakdown in the interface's logical flow and can lead to dropped conversions in high-stakes moments like checkout or signup dialogs.

Consider these common scenarios where background scrolling causes problems: a user begins filling out a signup form in a modal, accidentally scrolls down and loses their place, then struggles to find where they left off. Or a customer is reviewing product details in a quick-view modal and swipes the wrong direction, scrolling the product listing behind it instead. These friction points accumulate and can significantly impact conversion rates on e-commerce and lead-generation sites, making proper dialog implementation essential for conversion-optimized web experiences.

The Role of Dialog State Detection

The first step in implementing scroll lock is detecting when a dialog is open. Native <dialog> elements add an open attribute to the DOM when displayed, providing a reliable selector for CSS-based solutions. This attribute serves as a clear state indicator that can be leveraged with modern selectors like :has() to conditionally apply scroll-locking styles.

Custom modal implementations typically toggle classes on a wrapper element or the body itself to indicate open state. These class-based approaches require coordinating between the JavaScript that opens the modal and the CSS or JavaScript that manages scroll behavior. The goal in every case is to create a direct, reliable connection between dialog state and scroll permission on the underlying page. Modern approaches favor CSS-only solutions that respond to dialog state automatically, reducing the JavaScript surface area and potential for synchronization bugs. When the dialog opens, CSS rules should engage; when it closes, those rules should disengage, all without explicit JavaScript handling of the scroll behavior itself.

CSS-Only Solution Using the :has() Selector

The CSS :has() selector revolutionized how we handle scroll locking by allowing parent selection based on child state. Combined with the open attribute that dialog elements receive when displayed, we can create a powerful one-liner that handles scroll locking entirely in CSS. The :has() selector represents a breakthrough in CSS capabilities because it enables conditional styling based on descendant elements, something that was previously impossible without JavaScript.

The elegance of this solution lies in its declarative nature. No JavaScript needs to be written or maintained to handle the scroll locking logic. The browser handles the state transition automatically, and the CSS rules engage precisely when needed. This reduces potential points of failure and makes the code easier to reason about and maintain over time. As noted by Chip Cullen, who pioneered this approach, the selector detects when any element matching .dialog has the open attribute present. When that condition is true, the body receives overflow: hidden, preventing scrolling on the document. When the dialog closes and the open attribute is removed, the overflow: hidden rule is automatically lifted, restoring normal scroll behavior.

Combining with :modal Pseudo-Class

The :modal pseudo-class provides an additional layer of specificity for targeting only modal dialogs rather than any dialog element. Modal dialogs, by definition, require user interaction before returning to the main page context, making them the primary use case for scroll locking. Non-modal dialogs may intentionally allow background interaction, and the :modal selector helps maintain this distinction at the CSS level.

When your page uses both modal and non-modal dialogs, the :modal pseudo-class ensures scroll locking is applied only where semantically appropriate. The combined selector looks like this:

body:has(dialog:modal[open]) {
 overflow: hidden;
}

This approach is particularly useful in complex applications with multiple dialog types, such as a combination of alert dialogs (modal) and tooltip-style popovers (non-modal). By targeting only :modal elements, you prevent scroll lock from triggering on popovers while ensuring it activates for true modal overlays.

Chrome 144+ and overscroll-behavior: contain

Chrome 144 introduced a significant enhancement to the overscroll-behavior property: it now works on non-scrollable scroll containers. According to CSS specification updates, this change enables a pure CSS solution for preventing page scrolling when a dialog is open without needing the :has() selector or JavaScript. The MDN documentation defines overscroll-behavior as a property that controls the browser's behavior when a scroll boundary is reached, and the contain value specifically prevents scroll chaining.

This enhancement represents a standards-compliant solution that addresses a key limitation of the :has() approach. While the :has() selector modifies the body's scroll state, the overscroll-behavior approach contains scroll events at the gesture capture level without affecting the underlying page's scrollability. The key insight is that setting overflow: hidden on the dialog's ::backdrop pseudo-element creates a scroll container that can receive overscroll-behavior properties.

How This Approach Works

The overscroll-behavior: contain property prevents scroll chaining, which occurs when scrolling reaches the boundary of a container and the scroll action propagates to a parent element. In the context of dialogs, this means that scroll gestures that would normally continue through to the body are contained within the backdrop layer instead. The ::backdrop pseudo-element covers the entire viewport behind the dialog, and by making it a scroll container with overflow: hidden and applying overscroll-behavior: contain, scroll events are trapped within this layer.

This approach elegantly solves the scroll lock problem without modifying the body's scroll state, which can cause issues with scroll position restoration and layout shifts. The dialog remains the sole scrollable entity, and background scrolling is prevented at the gesture capture level rather than by disabling the body scrollbar. This makes it particularly suitable for dialogs with scrollable content, where the :has() approach might inadvertently prevent the dialog content from scrolling.

JavaScript Approaches for Broader Compatibility

For projects requiring maximum browser compatibility or more complex scroll lock logic, JavaScript provides reliable fallback approaches. As documented by CSS-Tricks, the traditional method involves setting overflow: hidden on both the html and body elements when a dialog opens. JavaScript fallbacks become necessary when you need to support older browser versions that don't support the :has() selector or when your dialog implementations require complex scroll position tracking and restoration.

The trade-off compared to CSS-only solutions is increased code complexity and maintenance burden. JavaScript solutions require coordination between dialog open/close events and scroll state management, creating more potential points of failure. However, they also offer more control over scroll behavior and can handle edge cases that CSS solutions might miss. For enterprise applications or legacy systems, professional web development services can help implement robust scroll locking that works across all target browsers.

Accessibility Considerations

Focus Management

Scroll locking is closely related to focus management for dialogs. When a dialog opens, focus should move to the dialog or its first focusable element, and focus should be trapped within the dialog while it remains open. As CSS-Tricks notes in their coverage of dialog accessibility, the combination of proper focus management and scroll locking creates a complete accessible modal experience. Native <dialog> elements handle focus trapping automatically, but custom modals require explicit implementation to prevent keyboard users from tabbing to background content.

Screen reader considerations are equally important. Users navigating via keyboard should not be able to tab to background content while the dialog is open, and screen readers should announce the modal presence without being interrupted by background scrolling. WCAG guidelines specify that modals should manage focus properly, including moving focus to the dialog when it opens and returning it to the trigger element when it closes. For comprehensive accessibility compliance, pair your scroll locking implementation with proper ARIA attributes and focus management. Our UI/UX design services include accessibility auditing to ensure your modals meet WCAG 2.1 AA standards.

Touch Action Considerations

On touch devices, consider using the touch-action property on the dialog backdrop to prevent touch scrolling gestures from reaching the underlying page. This provides an additional layer of protection against unwanted scrolling on mobile devices, complementing the overflow: hidden approach.

Reduced Motion Preferences

Some users prefer reduced motion and may be negatively affected by sudden layout changes or scroll behavior modifications. Consider respecting the prefers-reduced-motion media query when implementing scroll lock, particularly if your implementation includes animated transitions or layout shifts:

@media (prefers-reduced-motion: reduce) {
 body:has(dialog[open]) {
 transition: none;
 /* Still apply overflow: hidden for scroll lock */
 }
}

The scroll lock behavior itself should remain consistent regardless of motion preferences--the purpose is still to prevent unwanted background scrolling. However, any transitions or animations associated with dialog opening/closing should be minimized or eliminated for users who prefer reduced motion. This demonstrates respect for user preferences and aligns with accessibility best practices.

Best Practices Summary

Implementing scroll locking for dialogs requires balancing simplicity, compatibility, and user experience. Based on verified sources and modern development practices, these recommendations emerge as the most effective approach.

Prefer CSS-only solutions when browser support allows. The :has() selector approach provides excellent browser support in all major browsers as of 2025 and requires no JavaScript maintenance. This should be the default choice for most projects. Use overscroll-behavior: contain for Chrome-focused applications where serving users with modern browsers can be assumed and you want a solution that doesn't modify body scroll state. Always test scroll locking behavior across devices and browsers, paying particular attention to edge cases like nested scrollable content and rapid open/close sequences.

Track and restore scroll position when using JavaScript-based locking to prevent users losing their place in the page. Ensure dialog content is appropriately sized or uses internal scrolling instead of body scroll locking when modals contain long content. Use feature detection or progressive enhancement to provide the best experience supported by each browser. Consider touch-action properties on mobile to prevent unwanted scroll gestures from reaching the underlying page.

Common Pitfalls and How to Avoid Them

Several common mistakes can undermine scroll locking effectiveness. Understanding these pitfalls helps you build more robust implementations.

1. Forgetting Scroll Position Restoration

JavaScript-based scroll locking must track and restore scroll position when unlocking. Otherwise, users lose their place in the page. The implementation shown earlier captures scrollY before locking and restores it after unlocking using window.scrollTo(). Always test by opening a dialog, scrolling the page, closing the dialog, and verifying you return to the exact same position.

2. Scroll Locking with Scrollable Dialog Content

Applying overflow: hidden to the body when the dialog itself contains scrollable content can trap users without access to the dialog's content. This is particularly problematic for long forms or detailed content modals. The solution is either to use overscroll-behavior: contain instead, or to ensure the dialog element handles scrolling internally by setting overflow: auto on the dialog content area while leaving the body scrollable.

3. Incomplete Keyboard Navigation Blocking

Some implementations allow scrolling through keyboard navigation (arrow keys, Page Up/Down) while blocking mouse/touch scrolling. Test with keyboard-only navigation to ensure all scroll paths are blocked. This is especially important for accessibility, as many users rely on keyboard navigation.

4. Race Conditions in Rapid Open/Close Sequences

If users can quickly open and close dialogs, you may encounter race conditions where scroll state gets out of sync. The CSS-based solutions avoid this naturally because the browser handles state transitions atomically. With JavaScript solutions, consider debouncing open/close operations or using a flag to prevent re-entrant calls.

Conclusion

Preventing page scrolling while a dialog is open has evolved from a JavaScript-heavy challenge to a CSS-native capability. The :has() selector provides broadly supported, elegant solutions for most use cases, while Chrome 144's enhancement to overscroll-behavior offers a standards-compliant approach that respects scroll state more gracefully. By understanding these techniques and their trade-offs, developers can create modal experiences that keep users focused and conversion-ready.

The key takeaway is that scroll locking is not merely a technical detail but a user experience fundamental. When users open a dialog, they enter a focused interaction context. The interface should reinforce that focus through visual, behavioral, and scroll-locking cues that guide attention and prevent accidental navigation. This subtle detail signals professionalism and attention to user needs--qualities that contribute to higher engagement and conversion rates across your digital properties.

For most projects, start with the CSS :has() approach and add the overscroll-behavior enhancement for Chrome users. Use JavaScript fallbacks only when necessary for older browser support or complex requirements. Always test across devices, respect accessibility requirements, and prioritize user-centered design principles in your implementation choices. Need help implementing polished, accessible dialogs? Our UI/UX experts can help ensure your modals provide exceptional user experiences.

Sources

1. Bram.us: Use overscroll-behavior: contain to prevent a page from scrolling while a dialog is open
2. Chip Cullen: How to stop page scrolling when you have an open dialog element
3. CSS-Tricks: Prevent a page from scrolling while a dialog is open
4. MDN Web Docs: overscroll-behavior
5. MDN Web Docs: :has() selector