[SF_ACC][1.2.0][DynamicPageTitle] Items of overflow button cannot be navigated using arrow keys

[i323808]

Describe the bug There are two accessibility issues of items in overflow button:

1. Items in popover of overflow button cannot be navigated using arrow keys;
2. The item count(e.g. 1 of 2) is not announced by screen reader.

Isolated Example https://sap.github.io/ui5-webcomponents-react/?path=/docs/layouts-floorplans-dynamicpage--with-custom-overflow-button

To Reproduce Steps to reproduce the behavior:

1. Go to https://sap.github.io/ui5-webcomponents-react/?path=/docs/layouts-floorplans-dynamicpage--with-custom-overflow-button
2. Click on Overflow button
3. Cannot navigate items in popover using arrow keys
4. The item count is not announced by screen reader

Expected behavior

1. Items in popover of overflow button can be navigate using arrow keys;
2. The item count(e.g. 1 of 2) is announced by screen reader.

Screenshots If applicable, add screenshots to help explain your problem.

UI5 Web Components for React Information @ui5/webcomponents version: 1.8.0 @ui5/webcomponents-react version: 1.2.0 Operating System: macOS Monterey Browser: Chrome

Additional context Add any other context about the problem here.

[Lukas742]

Hi @i323808

the toolbars are implemented according to the SAPUI5 implementation and UX guidelines.

• SAPUI5 DynamicPage
• OverflowToolbar

We also had an internal discussion about this topic and the reason behind not offering a keyboard navigation is, that the toolbar also supports input components, for which the navigation would break. That's why only the default tab navigation is used here.

By leveraging the respective toolbar props (actionsToolbarProps or navigationActionsToolbarProps), you still have the option to configure the toolbars inside the DynamicPageTitle yourself to achieve the desired behavior, but as this would create a discrepancy between the React implementation and the SAPUI5 implementation, I wouldn't recommend it.

I'm going to close this issue now as the SAPUI5 implementation would need to be adapted first and we have to wait for what our accessibility experts have to say about that. Please feel free to add a comment if you have new information about this.

[OliKei]

The fact an input is part of the toolbar does not force users to use the TAB key to navigate among the toolbar items. An input, when receiving focus, has to preselect all its text. In this state the arrow keys can be used to set focus to the last character (when using right). If the user again presses right (the focus is already after the last character) it would usually do nothing. But in this case the focus can move ahead to the next UI element after the input. That works with any type of input, in both directions, left and right aka previous and next UI elements.

Second, predictability and reliability requires the UI elements behave consistent to industry standards (-> is to use arrow keys) and also means the control always acts consistent, completely independent from any sizing constraint. Blind users cannot perceive the size of a control and therefore cannot adapt their navigation patterns to size-based changed interactions. Thus the behavior requires to be consistent at all time in any size.

Please reopen this ticket and get it solved so we reach great user experience, and predictable and reliable behavior for all users. Thank you.

[Lukas742]

Hi @OliKei

I'm going to check with our a11y experts and let you know of the outcome. Depending on it we will then reopen this issue.

[Lukas742]

Hi @OliKei

I just heard back from our UX/A11y experts and there are still open topics for discussion (e.g. how to handle Select, ComboBox, etc.) so until they are clarified I'll keep the issue closed, but reopen it once they are plans for arrow navigation.

However you could still implement that behavior yourself (as mentioned above).