[SF_ACC][Table]: Focused row of a table embeded in ObjectPage is not visible when using up arrow key to move focus up

[i323808]

Bug Description

Render a Table in the ObjectPage component and press the up arrow key to move the focus up, the focused row is invisible when the scrollbar is moved up.

Affected Component

No response

Expected Behaviour

The focused row is supposed to be visible when scroll up likes using the down arrow key to scroll down.

Isolated Example

https://stackblitz.com/edit/github-jjmatnyo-vvdgdtuo?file=src%2FApp.tsx

Steps to Reproduce

1. navigate to https://stackblitz.com/edit/github-jjmatnyo-vvdgdtuo?file=src%2FApp.tsx
2. scroll down to the bottom of ObjectPage
3. focus a table row
4. press up arrow key to move the focus up
5. the focused row is invisible when the scrollbar is moved up

Log Output, Stack Trace or Screenshots

No response

Priority

None

UI5 Web Components Version

2.12.0

Browser

Chrome

Operating System

No response

Additional Context

No response

Organization

No response

Declaration

• I’m not disclosing any internal or sensitive information.

[NHristov-sap]

Hello @SAP/ui5-webcomponents-table ,

Please take a look on this issue.

Best Regards,
Nikolay Hristov

[aborjinik]

Hi colleagues,
Removing the onBlur handler from the ObjectPage so that it sets the scrollPaddingBlock but does not remove it resolves the issue.
Could you please take a look?

[Lukas742]

Hi @aborjinik

The ObjectPage needs to programmatically set the scroll-padding via JS, because otherwise, if items in the header area are focused, the scroll behavior is incorrect.

When investigating the issue, I noticed that when navigating the table via arrow keys, the relatedTarget is always null. Since we check for the relatedTarget to reset the scroll padding, this causes the described behavior.

ObjectPage/index.tsx

          if (opNode && !e.currentTarget.contains(e.relatedTarget as Node)) { // as the `relatedTarget` is always null, this check is falsely `true`
            opNode.style.scrollPaddingBlock = '0px';
          }

I compared the behavior to the ui5-list and there the relatedTarget is available. Could you please check whether this is intended?

Here you can see the difference of the List and Table component: https://stackblitz.com/edit/github-jjmatnyo-3ad7jzd1?file=src%2FApp.tsx

[aborjinik]

Hi Lukas,

The Table component follows a different architectural approach compared to other web components. Specifically, the accessibility role is applied directly to the custom element itself, rather than to an internal element within the shadow DOM as it is common with other components. This design enables full use of ARIA attributes, such as setting IDRef relationships, which would otherwise be restricted due to shadow DOM encapsulation. In fact, this architectural shift was the foundation for how the new Web Components Table initiative began: SAP/ui5-webcomponents#4702

Since the role is assigned to the custom element, it must be the element that receives focus but if you put tabindex="-1" on a custom element with shadow DOM enabled, it makes all of the child elements non-tabbable. (This is actually unexpected, since tabindex usually does not propagate, and makes it so only people using a mouse can click the elements.) To address this, table rows intentionally do not use tabindex="-1" (unlike ListItems), meaning they are not focusable by default during rendering, but can become focusable when needed. As a result, there is no relatedTarget during focus transitions. But I don't consider this a table-specific issue. You would encounter the same behavior if, for example, you added a Text component and attempted to click on it, or any other component that follows a similar approach.

Hope this clarifies the table behavior. What is the reason for removing scroll-padding-top?