sr-only inside a div with overflow produces unwanted scroll in the document

[pladaria]

What version of Tailwind CSS are you using?

latest from: https://cdn.tailwindcss.com

What build tool (or framework if it abstracts the build tool) are you using?

none

What version of Node.js are you using?

none

What browser are you using?

Chrome

What operating system are you using?

Linux

Reproduction URL

https://codepen.io/pladaria/pen/KKJyXjR

Describe your issue

sr-only inside a div with overflow produces unwanted scroll in the document.

After removing the sr-only class the document scroll disappears:

A workaround is to add a "large enough" negative positioning to the element, like left: -100000px; right: -100000px. Not sure whether this has a11y implications.

This could be a Chromium bug. Not reproduced in Firefox

[adamwathan]

Yeah tricky one, I think this is just one of those weird quirks you run into because of this stupid hack we've all had to use forever to render screen-reader-only text.

In my testing wrapping the sr-only element with a relative wrapper seems to fix it in your case:

<div class="overflow-y-scroll border-red-500 border-4 w-1/6 h-80">
  <div class="bg-indigo-500 h-40"></div>
  <div class="bg-pink-500 h-40"></div>
  <div class="bg-indigo-500 h-40"></div>
  <div class="bg-pink-500 h-40"></div>
  <div class="bg-indigo-500 h-40"></div>
  <div class="bg-pink-500 h-40"></div>
  <div class="bg-indigo-500 h-40"></div>
  <div class="bg-pink-500 h-40"></div>
  <div class="bg-indigo-500 h-40"></div>
  <div class="bg-pink-500 h-40"></div>
  <span class="relative">
    <span class="sr-only">Settings</span>  
  </span>
</div>

I'm going to move this to discussions just because I don't think we can really change the implementation of sr-only without major risks and it's the same generally battle-tested implementation used by every other CSS framework. Best bet in these situations tends to be to find some way to work around it like the example I just shared — we've had similar issues putting sr-only content in table headings and had to do similar stuff 😕

[Scooter1337]

Could you perhaps add this to the docs? Just spent 30 minutes figuring out what was breaking my overflow. It was, like you mentioned, an sr-only in a table. Your workaround worked, so thanks for that.

[tabeatheunicorn]

Second that! I spent an entire day finding the problem due to the sr-only being in a very nested div

[yunhao]

We should include a notice and this workaround in the docs on https://tailwindcss.com/docs/screen-readers.

The sidebar component template from tailwindui.com uses a sr-only class inside each menu item. I ran into a problem when trying to create a layout similar to VS Code using the sidebar and flex. I looked through the docs and used developer tools to check for issues, but found nothing.

Adding a note and this fix to the guide would help save time for other developers.

[mtlehtin]

The scroll issue is due the absolute position style in the sr-only element. The element is hanging around as an invisible block outside the viewport which is then causing the scroll.

Another workaround is to use fixed position instead without any extra markup like:

<span class="sr-only fixed">Settings</span>

[filiptronicek]

Setting the position to fixed works pretty nicely, thanks for the suggestion. My only concern is that it might impact the order in which screen readers will announce the element, but my access to different screen reader software is limited and I can't hence make any conclusions.

To improve on the usability of this, one can tweak the global sr-only class so that you don't have to update all call sites of that class. What we ended up doing is adding the following to our global css file:

@layer utilities {
    .sr-only {
        clip: rect(0 0 0 0);
        clip-path: inset(50%);
        width: 1px;
        height: 1px;
        overflow: hidden;
        position: fixed;
        white-space: nowrap;
    }

    .not-sr-only {
        clip: auto;
        clip-path: none;
        width: auto;
        height: auto;
        overflow: visible;
        position: static;
        white-space: normal;
    }
}

[janglad]

just ran into this as well and fixed did indeed fix it. Is there a reason for this to not be the default?

[HyoKImAbsolut]

Same problem.

Some post says we can add top: 0 to solve this: FortAwesome/Font-Awesome#17481
while some says NO! : https://stackoverflow.com/questions/66572172/sr-only-class-causing-page-scroll

[lekevicius]

Adding to the crowd that wasted a lot of time on this. I never even suspected sr-only class, did a whole bunch of debugging of unrelated stuff (was it radix tooltip portals? flexbox min-w-0?) before finding out the real culprit - and I was very surprised.