visually-hidden text in table shows body scrollbar in Chrome

[steffen-harbich-cognitum]

Prerequisites

• I have searched for duplicate or closed issues
• I have validated any HTML to avoid common problems
• I have read the contributing guidelines

Describe the issue

I have a horizontally scrolled, wide table that contains visually-hidden text in the table head. This produces an unexpected body scrollbar in Chrome. Observation:

• Does not occur in Firefox.
• Does not occur when there is no visually-hidden text.
• Does only occur when the visually-hidden text is in the last columns that exceed the scrolled wrapper width.
• Does not occur when "position: fixed" is used for visually-hidden (but I guess this is not an option for a fix).

I don't know a workaround so far that doesn't have downsides for a11y.
Maybe this is a bug in Chrome itself.

Reduced test cases

See this reproducing example. Open in Chrome and reduce the window width (e.g. by dev tools) until a scroll bar appears for the body (ignore the table wrapper scrollbar, this is intended). Scrolling the body, you can see that the table wrapper does not exceed the expected width.

https://codepen.io/s4R8/full/myJGwrY

What operating system(s) are you seeing the problem on?

Windows

What browser(s) are you seeing the problem on?

Chrome

What version of Bootstrap are you using?

5.3

[julien-deramond]

Thanks a lot for reporting this use case with a CodePen, @steffen-harbich-cognitum 🙏
I can confirm the rendering issue on macOS with Chrome, Edge, and Safari, while it works correctly in Firefox.
Looks like this behavior existed even before c5bec4e and #37533.

In this specific case, adding .position-fixed to the .visually-hidden <span> appears to fix the issue by fully removing it from the layout flow, which prevents Chrome (and others) from collapsing the column width. However, this may cause the hidden content to become visually or semantically detached from the table context, so use with care.

It seems to be a rendering quirk in Chromium and WebKit-based browsers related to how table layout is calculated when a column contains only visually hidden content. Firefox handles this differently by preserving column width.

For now, I’d say the fix likely needs to come from the outside:

• either by cautiously applying .position-fixed (while ensuring a11y is preserved)
• or by exploring alternatives like setting a min-width, inserting a layout-visible spacer (e.g. a   outside .visually-hidden), or using table-layout: fixed, depending on the use case 🤷

If anyone has ideas or references in browsers trackers 🙏

Please also note that the issue is not observable in #41474 as it doesn't use the position: absolute, but a display: inline-block.

Maybe an interesting use case for you @ffoodd who maintains this French article https://www.ffoodd.fr/masquage-accessible-de-pointe/

[prachimaskar]

Hi! I'm new to GitHub contributions and just wanted to confirm that the   fix mentioned above works for me too.

I tested it in Chrome by adding   after the .visually-hidden span in the table header, and the body scrollbar issue was resolved without breaking accessibility.

Thanks for the detailed explanation and example! This was really helpful. 😊

[steffen-harbich-cognitum]

Thanks for looking into it. When I add the   in front or after the <span class="visually-hidden"> in my CodePen example, it still shows the scrollbar in Chrome for me. However, the approach with "display: inline-block" works well. @julien-deramond, do you see any negative impact of this approach in the table? As far as I tested, everything was as expected.

[julien-deramond]

do you see any negative impact of this approach in the table?

I don’t see any immediate issues with this approach, but it will likely depend on your actual use case beyond the CodePen example. In your real project, I’d pay particular attention to things like table width, responsiveness, keyboard focus (especially if the <td>, whose header uses a .visually-hidden class, contains focusable elements), and screen reader behavior.

If everything renders correctly, keyboard navigation works as expected, and screen readers interpret the structure properly, then this is probably a solid solution for your specific scenario.

[prachimaskar]

Following the discussion above, I tested the display: inline-block approach applied to the .visually-hidden span inside the table header.

🔍 Test Environment:
Chrome (latest), standard desktop viewport, using .my-table-wrapper { overflow-x: auto; } and td { white-space: nowrap; }.

✅ Results:

• No horizontal scrollbar appeared
• Table layout remained stable across zoom levels and window resizing
• Focusable elements (<button>) inside <td> worked correctly with keyboard navigation
• .visually-hidden content remained in the DOM and semantically valid for screen readers (though I couldn't fully verify audio output)

📌 Conclusion:
This fix appears stable and does not negatively impact layout, accessibility, or interaction in common use cases. Like Julien mentioned, edge cases (e.g. RTL layouts or complex headers with focusable elements) may still need individual testing.

Thanks to everyone involved — this testing helped me understand the importance of accessibility-aware styling in real-world components.