Context pad items are not accessible with the keyboard

[lmbateman]

Describe the bug

When I tab to the "improved" context pad and try to use Return or Space to activate a button inside it, nothing happens.

Steps to reproduce

1. Open a BPMN diagram.
2. In the Desktop Modeler, click an element to display the context pad. (This isn't necessary in Web Modeler.)
3. Press Tab until you reach the first button in the context pad.
4. Press Return. Observe that nothing happens.
5. Press Space. Observe that nothing happens.
6. Tab to the next button and press Return and/or Space. Repeat for all buttons.

Screen.Recording.2026-03-03.at.7.26.30.PM.mov

Expected behavior

• In most cases, pressing Return and Space when a context pad button is focused should activate the button. The exceptions are
  • The "Connect to other element" button, which probably isn't feasible with the keyboard at the moment
  • The Comment button - likely feasible to do something reasonable, but needs some consideration as to how it should work
  • The Annotation button - ditto
• I should then be able to navigate through the focusable elements in the popups using Tab.
• When I reach the last focusable item in a popup, pressing Tab should take me to the next button in the context pad.
  • The exception is Delete, since (a) there's no next button in the context pad, and (b) the context pad vanishes when the element is deleted. In this case, I suggest putting focus on the next focusable element after the context pad (the first button in the canvas tools for WM, the first focusable item in the properties panel for DM).

Environment

Camunda Modeler system information

• Version: 5.44.0
• Operating System: Mac OS 10.15.7
• Plugins: bpmn-js Token Simulation
• Execution Platform: BPMN - Camunda 8

Additional context

Web Modeler team requested this be moved from 21317 to the Core Modeling team.

[nikku]

@lmbateman could you attach a screen capture? This makes it easier to understand what you're reporting - I'd like to understand for example whether we target the "improved" or classic context pad here, or both.

[nikku]

@lmbateman I'd like to understand our general strategy for canvas accessibility. Do we want to deliver user value ("they can use our tools with the keyboard") or do we want to make things tabable - the later one can achieve the earlier outcome, but can also lead to being not usable in the standard case.

[lmbateman]

I'd like to understand for example whether we target the "improved" or classic context pad here,

Sorry for not specifying that. I was referring to the new context pad. It looks like focus never lands on the old one, at least in the DM.

Do we want to deliver user value ("they can use our tools with the keyboard") or do we want to make things tabable - the later one can achieve the earlier outcome, but can also lead to being not usable in the standard case.

Good question. The requirement is that keyboard users must be able to perform the same or comparable actions. That doesn't necessarily mean every visible control must be individually tabbable.

However, the Tab key is a standard method of navigating through web pages, and following platform conventions is important for usability as well as compliance. So I think we should support tabbing by default, unless we have a strong reason not to.

At the same time, we don’t have to force users to tab through everything. We can also provide additional access patterns, such as our existing keyboard shortcuts and carefully-considered navigation interactions on the canvas.

[ev-codes]

@lmbateman I went ahead and added a screen capture I created while trying to reproduce this. I also updated the PR description with the information you gave in your comment.

I think there's enough information in this issue to start work on it. However, it doesn't meet the urgency threshold (imo) to move to Ready. So I'll move it to the Backlog.

[lmbateman]

Thanks, @ev-codes!