Fix: FSE editor sidebar item scroll accessibility issue

[Kallyan01]

Closes #67959

What?

Fixes an issue where focused elements in scrollable lists with sticky headers or footers can remain hidden behind those elements when navigating using a keyboard or keyboard-like devices.

Why?

Sticky headers and footers are commonly used in the editor UI to keep certain elements fixed while scrolling. However, this pattern causes accessibility issues where focused elements are obscured. This is particularly problematic when navigating with a keyboard, as it prevents users from seeing the currently focused item. Additionally, browser behavior varies, with WebKit browsers centering focused elements and Firefox not doing so. A programmatic solution leveraging scroll-padding can improve accessibility and consistency across browsers.

How?

1) Site Editor Issue

We resolved the issue by restructuring the DOM elements within the Site Editor to address the accessibility concerns instead of using any dynamic approach like block manager one :

1. Reorganizing DOM Structure:

   • Moved the Title and Description elements to the top of the scrollable container and made them fixed.

2. Adjusting Scrollable Area:

   • Restricted the scrollable area to the list section only, leaving the fixed elements unaffected by scrolling.

3. Default Accessibility Improvement:

   • By limiting the scrollable area to the list, this approach inherently solves the accessibility issue where focused elements were previously hidden behind sticky headers or footers.

2) Block Manager Issue

The issue is resolved by dynamically adjusting the scroll position of the container based on the position of sticky elements and the currently focused element. Here's how it was implemented:

1. Identify Key Elements:

   • A scrollable container is selected using document.querySelector to target the relevant modal or scrollable content.
   • Sticky elements within the scrollable container are identified using querySelectorAll.

2. Focus Handling:

   • An event listener is added to the container to monitor focusin events, which are triggered whenever an element inside the container gains focus.
   • A utility function, getActiveStickyElement, determines the currently active sticky element based on its position relative to the scrollable container.

3. Scroll Adjustment Logic:

   • When an element inside the container gains focus, its position is compared to the bottom of the sticky element.
   • If the focused element is hidden behind the sticky header/footer, the scroll position of the container is adjusted using scrollTo with the smooth behavior for a better user experience.

4. Event Listener Cleanup:

   • The event listener is removed during the cleanup phase of the useEffect hook to avoid memory leaks or unintended behavior when the component unmounts.

Testing Instructions

Testing Instructions for Keyboard

Site Editor Navigation Panel:

Go to the Site Editor > Patterns.
Ensure the navigation panel has enough patterns to make it scrollable.
Use the Tab key to navigate the patterns in the list.
Scroll down and then use Shift+Tab to navigate backwards.
Confirm that focused elements are no longer hidden behind the sticky header.

Preferences Modal Dialog:

Open the Preferences Modal Dialog > Blocks.
Ensure the list of blocks is long enough to make the panel scrollable.
Use the Tab key to navigate and then Shift+Tab to navigate backwards.
Confirm that focused elements remain visible during navigation.
Test across different browsers (e.g., Chrome, Safari, Firefox) to ensure consistent behavior.

Screenshots or screencast

Screen.Recording.2025-01-17.at.10.22.24.PM.mov

Screen.Recording.2025-01-17.at.9.47.58.PM.mov

[github-actions]

👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @Kallyan01! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: First-time Contributor.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Kallyan01 <[email protected]>
Co-authored-by: afercia <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.