Accessibility - keyboard traps

[ghowardibm]

Hi,

The product I work on consumes the monaco-editor and we're currently ensuring accessibility compliance throughout our user experiences. One thing we noticed during our keyboard navigation testing is that user can get trapped once focus is inside the editor. We're aware of the shortcutCtrl+Shift+M and then Tab that allows focus to shift forward away from the editor so it's possible for the user to escape. However the same cannot be said for using the same shortcut and then Shift+Tab to go to previous element. There are a few things I wanted to start a discussion on and get some guidance, or even if this is a bug that I should raise an issue for.

1. The standard recognised Esc key is not supported to remove focus from the editor, has this been considered at all or is there a conflict with using this shortcut or other standard recognised keys to be used as the main escape from focus?
2. I'm reading some different things about keyboard traps and violating this accessibility requirement. Some content describes not being able to move freely (forwards and backwards) as a keyboard trap. Moving forward via the custom shortcuts documented and listed above at least means the user is not completely trapped. But I wondered if you had considered this issue of only being able to escape forwards to next element?
3. A side note to the above, Ctrl+Shift+M on Macbook keyboards would be rather difficult to execute with one hand for a user that requires this type of accessibility.

Any thoughts, guidance and comments appreciated.

Thanks.

[MILLER (MILLERMARRU)]

The relevant feature is documented as "Tab Trapping" in the Accessibility Guide: by default Tab inserts a character, and Ctrl+M (Windows/Linux) or Ctrl+Shift+M (macOS) toggles that off so Tab moves focus out of the editor instead. It's described as a single toggle on the Tab key's behavior, not two separate forward/backward bindings, which is what makes your finding notable: once toggled, Tab and Shift+Tab should logically behave symmetrically, since they're the same underlying "does Tab insert or move focus" mode, just triggered with the modifier reversed.

I couldn't find anything in the accessibility guide describing Shift+Tab as a documented exception to that toggle, so the asymmetry you're describing (Tab escapes forward, Shift+Tab doesn't escape backward, both after the same toggle) looks like a genuine bug rather than an intentional forward-only design, though I'd want that confirmed by someone who's actually traced the focus-trap code before calling it definitively a bug. I'd raise it as an issue with a minimal repro (toggle Tab Trapping, focus first element in editor, Shift+Tab, observe focus stays trapped) rather than a discussion, since "should be symmetric per the documented toggle but isn't" is a concrete, testable claim.

On Escape specifically: the guide only documents Escape for returning focus to a specific position after using "Go to Next/Previous Error" (F8) or the Diff Review Pane, not as a general "exit the editor" shortcut, so that part isn't a gap in the docs, Escape genuinely isn't meant to be a blanket focus-trap release today. And your Ctrl+Shift+M one-handed concern on macOS is worth including in the same issue, that's a real ergonomics point independent of the Shift+Tab bug.