Reason for no ability to control scroll lock on dialog

[claudesortwell]

I think headless UI is amazing, but I feel like the the ability to scroll on the outside of a Dialog is very useful in some cases (e.g. slide over) and with such a barebone UI library, I would think it would not be forced or at least controllable.

I was wondering if their was some reason of not exposing the ability to adjust or disable the scroll lock on a dialog?

If not I'm more than happy to open a pull request for it.

[ragulka]

I have the same question. I have a use-case where I have a form inside the slide-over and the document renders a preview as the user fills in the form inside the slide-over. Since the preview can get quite long, I want the user to be able to scroll it, even with the slide-over being open.

[RobinMalfait]

Hey! Thank you for your suggestion!
Much appreciated! 🙏

When working with a Dialog, you have to think as if it is a separate page. From an accessibility perspective, screenreader users are not able to interact with the content outside of the Dialog. That's one of the reasons why we have focus trapping going on.

Being able to scroll in the background, is technically interacting with the "outside world".

While we could provide an option to disable this behaviour, it makes that content for sighted users accessible, but it will still not be accessible for screenreader users or people that use other assistive technology, which will make this option a no-go.

Instead, what you could do is not use a Dialog at all, keep it visually the exact same way. You do lose other features if you don't use a Dialog. But you have to decide what kind of features you want while keeping accessibility in mind.

[ragulka]

Thanks for the clarification! I do appreciate that Headless UI takes care of the best practices with regards to accessibility, but there are always edge cases where some level of customization is needed. I'm not sure forcing developers to use scroll lock with Dialog is the best way to ensure accessibility, though...

Considering my example above, scrolling the preview in the background for sighted users would only benefit them anyway, as users with no sight would not "see" the preview anyway. Basically, it would be sort of a progressive enhancement, if you will. As such, scrolling in the background would effectively make no difference to non-sighted users at all. They won't notice or care whether the background scroll is locked or not. Does that make sense or am I missing something?

[ragulka]

Just to clarify a bit further - in my use-case, it would actually make a lot of sense to use a Dialog (slide-over), because it adapts perfectly to mobile: it can be thought of as a separate screen. On desktop, however, sighted users would also see how the form they are filling affects the final design/preview. Taking away the ability to scroll the page from sighted users does not seem to benefit screenreader users in any way. Also, using Dialog does make sense even for sighted users and on desktop as well, as it handles all of the other behavior (keyboard, focus trapping, clicks outside, etc...).

I could just build a custom component with the same design and behavior, but I would end up having to re-implement pretty much everything from Dialog besides scroll lock. That's one of the things that I was hoping Headless UI would not force me to do and why I used to like - believe it or not - jQuery UI back in the day: it was always possible to customize to your use case.

Finally, even if we were to not use a Dialog at all, I don't see that the lower-level components like FocusTrap have any documentation right now, and just by looking at Dialog itself, I'm not sure how it prevents the first focusable element from jumping into view without the transition? When I try to recreate the Tailwind UI slideover without the Dialog parts, and just using TransitionRoot, Transition and FocusTrap with a focusable element inside, the enter transition never happens - it just immediately jumps into view.

I'd rather not spend time figuring these things out if it's already been figured out, and having a few options to control various features of the Dialog could help it adapt to a few more situations. As another similar example, consider this from Jonathan Reinink: https://twitter.com/reinink/status/1385599328350318594?s=20

[claudesortwell]

@ragulka Headless UI, is and probably always put accessibility first which is great.

To get this behaviour in react all you need to do is something like this (timeout is if you have a transition):

useEffect(() => {
    if (open) {
      setTimeout(() => {
        document.documentElement.style.overflow = 'unset';
      }, 1000);
    }
}, [open]);

[ragulka]

@RobinMalfait correct me if I'm wrong, but the ARIA guidelines do not mention anywhere that the scroll should be locked when a Dialog is open.

Is there a technical reason not to allow toggling scroll-lock? I'm asking because now that HeadlessUI supports nested Dialogs (stacking context), it's becoming more and more tedious trying to re-implement 99% of what Dialog does (as you suggested), just without the scroll-lock part.

[mtayyab0112]

You can add simple these lines in your css file this will resolve the issue

 html {
    overflow: auto !important;
    padding: 0 !important;
  }

[sefai]

I'm not sure if I am requesting the same thing with the authors but scroll lock troubles me in my scenario: I'm using a Dialog to control some filters that is showing some items on an Infinite Scroll page. When I scroll down to let's say 3rd page, open the Dialog, and apply a filter I need to reset the page which means I need to start showing the items from the first result in my infinite scroll page. But as soon as I close the Dialog, (there is only one page of items in the page), the Dialog tries to restore the scroll position which causes the page to be scrolled to the bottom and that causes Infinite Scroll logic to kick in and request the next page. So the user needs to scroll to top to see the first page. I need a way to scroll to top after applying a filter.

scroll_issue.mp4