Consider preventing page scroll when modal dialog is visible

[scottaohara]

Another UX/a11y improvement for the dialog element would be to ensure that, when in the modal state, the underlying document cannot be scrolled. This will help ensure that the invoking element for the dialog will remain in the visible viewport, and when focus is returned to the document, the viewport will not have to re-scroll to ensure this element is in view. This topic was originally surfaced by Curtis Wilcox on the web a11y slack channel.

I have created a quick demo to show how the underlying document is presently scrollable while the modal dialog is visible: https://codepen.io/scottohara/full/YzYGpNy

One caveat I can think of with this idea is that if an author makes a dialog that is too large for the current viewport, then the underlying document will need to be able to scroll so as to allow someone to view all the content of the dialog.

Though, one could also argue that this could be, at least partially, mitigated by setting a max-height/width to the dialog so that it does not extend beyond the bounds of the browser viewport. Authors will need to do something like this to some degree to meet wcag success criterion 1.4.10: Reflow.

[extra808]

Thank you Scott for raising the issue here.

If scrolling the underlying document is to be prevented, I think to be thorough it would also need to be prevented in any child scrollable element not in the modal dialog.

Scott's demo includes an option, Enable overscroll-behavior: contain, an example of how the issue could be mitigated. I've found in Firefox (v98.0.1 for Mac) the property doesn't prevent scrolling at all and it doesn't always prevent scrolling in Chrome (v99.0.4844.83 for Mac). As mentioned in the demo, it doesn't prevent keyboard keys from scrolling the document; since it also doesn't prevent clicking and dragging the document scrollbar, this is more equitable behavior (the dialog ::backdrop prevents use of scrollbars within the document).

A well-designed modal dialog should include whatever information is needed to complete the intended tasks within. Nevertheless, there could be situations where it's beneficial to users who can see the underlying document to be able to still scroll it: A product in a dialog shopping cart can be compared to products listed in the underlying page; while filling out a form in a dialog, someone with difficulty recalling information from the page may be able to scroll it into view. All of this is dependent on how visible the document is through the ::backdrop and what the modal dialog is covering.

[nt1m]

Is blocking scrolling something we should special case for <dialog> ? or should we do this to all nodes that are inert?

I think forcing overflow: hidden may be a bit disruptive for websites where some content is expected to be visible just with overflow: visible, especially if done for all inert nodes. We may be able to force overscroll-behavior: contain though I don't know how this solves this particular issue.

Special casing <dialog> isn't particularly great IMO.

[scottaohara]

@nt1m good point about not wanting to special case, completely agree.

There definitely could be benefit to doing this for other inert nodes, especially if they represent other types of 'popups' where focus navigation should be trapped to the popup so long as it is invoked - and thus accidentally scrolling the underlying document in those cases could either result in an unwanted dismissal of the popup, or a visual separation of the popup from its invoking element.

But, maybe this is more an explicit opt in for authors? Whether that be an html feature to do so, or author guidance on how to do this to in a standardized way. I can think of both situations where I'd absolutely want this, and others where it'd be less than ideal.

[benfrain]

Just hit this issue and wondered what the current consensus is? Arrived here having done what I consider the 'common sense' thing and applied overscroll-behavior: contain to the dialog to ensure the trigger for what caused the dialog in the first place remains in situ.

Is the current situation that there is no 'proper' way to prevent overscroll with dialog elements?

[trickydisco78]

This has also come up for me today. I followed Adam Argyles excellent article : https://web.dev/building-a-dialog-component/

Although it;s come back that they expected the whole page to scroll rather than content inside the modal/dialog. I guess the default behaviour is inert which blocks focus and click events. It could be argued you are no longer interacting with whats behind the modal so it shouldn't scroll.

Also fromthe w3c

. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.
A

Adam just responded on twitter

Scrolling shouldn't happen behind the modal, things behind the modal should be considered inert / hidden

[simevidas]

CSS provides a way to do this:

dialog {
  overflow: auto;
  overscroll-behavior: contain;
}

This should work in browsers, but it doesn’t because they all have the same bug: w3c/csswg-drafts#3349 (comment).

I think the best path forwards is for browsers to fix this bug.

[pepkin88]

This should work in browsers, but it doesn’t because they all have the same bug: w3c/csswg-drafts#3349 (comment).

But will it work also, when the pointer is over the backdrop area and the mouse wheel is used?
Because currently, even when the dialog is scrollable and the overscroll-behavior blocks the scrolling outside when my cursor is over the dialog area, it doesn't block when the cursor is over the backdrop area.

Also for scrolling with keyboard it doesn't seem to work at all.

[simevidas]

@pepkin88 When I do this:

dialog, ::backdrop {
  overscroll-behavior: contain;
}

attempting to scroll while the cursor is over the backdrop:

• Chrome: scrolls the dialog
• Safari and Firefox: scrolls the page

Test page: https://output.jsbin.com/puwojoy/quiet

I assume Chrome’s implementation is acceptable. In that case, we should investigate why the other browsers behave differently and maybe try to get them to align with Chrome.

---

Regarding scrolling with the Arrow Up and Down keys while the dialog is open (same test page):

• Chrome: page starts scrolling after dialog scrolls to end (overscroll-behavior: contain is ignored)
• Safari and Firefox: page does not start scrolling in this case

This seems to be a five-year-old Chromium bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=824555