Actionsheet: Keyboard focus is not moving during navigation when JAWS is on and role of actionsheet is set to menu

[pankajpandey01]

Describe the bug
Please see details here: SAP/ui5-webcomponents-react#3887.
This is reopening of above defect.

Additional context
Our a11y team expect ActionSheet should behave like
https://www.w3.org/WAI/ARIA/apg/patterns/menu-button/examples/menu-button-actions-active-descendant/

Stakeholder
Organization: {SuccessFactors}

[Lukas742]

Hi @pankajpandey01

please add a detailed description of what problem you're facing and why the provided solution in the original issue is not sufficient.

[pankajpandey01]

As described in SAP/ui5-webcomponents-react#3887, when JAWS screen reader is on, Keyboard focus is not moving during navigation. This issue happens when actionSheet role changed to menu. As per our a11y requirement, we need role as menu. Please provide solution with actionSheet role as menu.

[Lukas742]

I gave an explanation and solution to this question in the original issue, and in my previous comment I kindly asked you to describe why that is not sufficient. So please do that.

[pankajpandey01]

Hi @Lukas742
As per your solution, role="application" has to be enforced on application or component level. We do not want role as application, we need role as menu for actionSheet as per a11y requirement. We can not set our page/application level role as "application" as page contain some non application normal web content. Can you please suggest your solution by some example on top of https://codesandbox.io/s/react-playground-forked-zrm65p ?

[Lukas742]

Setting the role of the component to application doesn't necessarily mean that you cannot set another role to sub-elements. Therefore if you really only need this on component level, you can set it directly to the ActionSheet.
If you're only consuming components from UI5 Web Components for React in your application, it's most probably better to globally attach this role, as ui5-webcomponents are accessible out of the box and don't need traditional HTML interpretation techniques. You can do that for example directly on the body of the page, or on the root element of your React application.

Here you can find an example where the role is only applied to the ActionSheet component.

[pankajpandey01]

Hi @Lukas742
We want to update on component level. I tried above comment example and still see original issue.

[Lukas742]

Hi @pankajpandey01

I can confirm that it doesn't work like this with JAWS and neither does setting role="application" to the body element.
Since this is related to the ui5-responsive-popover and/or JAWS, I'm going to transfer this issue to the ui5-webcomponents repo, so our colleagues there can look into this.

---

Hi colleagues,

we have a strange behavior when using role="application" with JAWS. In our ActionSheet we apply custom keyboard navigation, by leveraging the keydown event. When a screen reader is used, app developers should be able to prevent the custom focus handling of the screen-reader by setting role="application". When using a ResponsivePopover, this is working without any problems with NVDA, but doesn't with JAWS.

Using Buttons and setting role="application" to the container div it works as expected: --> codeSandbox (wcr)

Only when a ResponsivePopover is used, the logic doesn't work anymore with JAWS --> codeSandbox
Note that it doesn't matter if we're setting the role to the web-component itself, or the most outer element (body), the screen-reader's custom navigation is still taking place and the native focus doesn't move. This is only happening with JAWS, NVDA is working fine.

To reproduce:

1. Open JAWS
2. Open the first codeSandbox
3. Navigate between the buttons by using the arrow keys.
4. See that the native focus is being applied
5. Open the second codeSandbox
6. Open the popover and navigate between the buttons by using arrow keys.
7. See that the native focus doesn't move.

We're not sure if this is an issue with the web-components, or JAWS. Could you please take a look?

[nnaydenow]

Hi @SAP/ui5-webcomponents-topic-rd

Could you please check please check why the focus is not moving inside popover when the JAWS is used?

Regards,
Nayden

[LidiyaGeorgieva]

Hello @pankajpandey01 ,

The difference between the two samples (first codeSandbox and second codeSandbox ) is the position of role="application".
This difference makes Jaws to behave differently, which is not under our control.
You can see more information about this role here: https://www.a11yproject.com/posts/how-to-use-application-role/

Regards,
Lidiya

[Lukas742]

Hi @LidiyaGeorgieva

please read what I wrote about the behavior of role="application". I already outlined that screen readers behave differently when using this role, but it's not the issue here. The issue is that JAWS is ignoring the role in this case and doesn't behave differently.

[LidiyaGeorgieva]

Hello,

Seems changing the position of the role="application" fixes the issue with Jaws:

This has no relation with the responsive popover rather the role="application" usage.

Regards,
Lidiya

[Lukas742]

Hi @LidiyaGeorgieva

applying the role inside the slot is working, but it's not working when applied directly on the web-component (ui5-responsive-popover) or somewhere else in the DOM tree (e.g. body) which is pretty common when using components that are fully accessible out of the box, because this way developers don't have to set the role on each component, but only in one place.
Also, setting it inside the content of the popover (default slot), is currently not possible with our implementation as we're already applying a role there (other than "application"). We could add another element wrapping the content, but I would like to know why that is necessary, to prevent future problems.

With NVDA it's working no matter where the role is set. So I'm wondering if this is an issue with JAWS and it's general web-components support, or if this is an issue with JAWS and the ui5-webcomponents support, or if it's something within the ui5-webcomponent itself that needs to be adjusted.

[TeodorTaushanov]

Hi @Lukas742,

Unfortunately we cannot control how the screen readers virtual cursor will affect the keyboard navigation.

I would suggest you to avoid using role="application", as It is used to denote a region of a web application that is to be treated like a desktop application.

This looks like some JAWS specific behavior. I'm not sure if this is a bug in JAWS. But you shouldn't put role="application" to avoid some screen reader issues.

Best,
Teo

[Lukas742]

Hi @TeodorTaushanov

I understand, thanks for the clarification.

I'll discuss with the team on how we should handle such issues in the future.