DMN elements - Scrollable region must have keyboard access

[vpellegrino]

Describe the Bug

The hit policy selector and the DMN table are affected by accessibility issue: Scrollable region must have keyboard access.

AXE recommendation:
To solve this problem, you need to fix at least (1) of the following:

• Element should have focusable content
• Element should be focusable

Steps to Reproduce

1. Open the DMN editor (for example on the Web Modeler)
2. Open the hit policy selector
3. Resize the page so that the internal scrollbar appears on both elements (see screenshot)
4. Execute the page scan, by using the "axe DevTools" extension

Expected Behavior

No accessibility issue is reported by the axe scan.

Environment

Please complete the following information:

• Browser: Chrome
• OS: macOs
• Library version: current one (reproducible on https://demo.bpmn.io/dmn/new)

[nikku]

Thanks for opening this issue. I guess we'll find some more issues related to a11y if we use axe extensively.

[nikku]

Confirmed this to be an actual issue, cf. recording:

---

From the spec text: It's goal is to ensure that "Scrollable content can be reached with sequential focus navigation". Under "Assumptions" the spec writes:

This rule assumes that all scrollable elements with visible content need to be keyboard accessible. Scrollable elements that do not need to be keyboard accessible, perhaps because their content is purely decorative, the scroll area is whitespace, or because scroll can be controlled in some other keyboard accessible way such as through a button or custom scrollbar, may fail this rule but still satisfy success criterion 2.1.1 Keyboard.

---

What we violate:

• While we are a partial keyboard trap (including ESC) the user cannot tab through the entries to select one.

[barmac]

The hit policy widget is a Select-only Combobox. There is already keyboard access to the options via arrow keys. We may want to annotate the control better though so that axe understands the its purpose.

[nikku]

@barmac The point is that nothing can be selected using keyboard right now (using tabbing). This is the bug we need to fix. Alternatively, yes, we can promote arrow keys.

[barmac]

Not on my machine?

Screen.Recording.2024-03-18.at.10.53.35.mov

[barmac]

This was tested on https://demo.bpmn.io/dmn

We should NOT scroll to the select options via TAB.

[barmac]

The only issue I see right now from the keyboard perspective is that TAB out does not close the options.

[nikku]

My expected behavior:

• 🅰️ I can tab through the options to select, and ESC closes the widget
• 🅱️ I cannot tab through the options, use arrow keys only, but then loosing focus shall close the widget.

[barmac]

🅱️ is what I'd expect

[nikku]

Verified arrow key (only) navigation on select elements.

@barmac What about turning it into a simple select? Why do we make it a custom component in the first place?

[barmac]

I am OK with plain HTML experience.

[nikku]

I'm de-prioritizing this item and adding to our a11y list.

[barmac]

Fixed via #843

[nikku]

Fixed via 6825860.