Accessibility issue: Can't move cursor back to the main editor from chat pane

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

This is an accessibility issue for blind users - using cursor with Screenreader (NVDA).
This started from one of the recent versions (I started experiencing this about a week ago).
This makes cursor much harder to use for blind people because we lost an ability to jump between chat and main editor in a single keystroke. In the end I found a workaround, but it involves tens of keystrokes - I have to open file explorer and find the right file there. Very tedious.

Steps to Reproduce

  1. Run Cursor on Windows, use NVDA screen reader. Turn on accessibility mode in Cursor.
  2. Open some file. Press control+L to open chat pane.
  3. Try to go back to the editor using keyboard commands only. No mouse.

Expected Behavior

Pressing control+L again should take you back to editor pane. In fact, it closes the chat pane visually, but it doesn’t focus the main editor.
Pressing control+shift+E twice should also take you back to the main editor - that’s VSCode command. In fact, the focus gets stuck in the file explorer pane.

Operating System

Windows 10/11

Version Information

Version: 3.1.17 (user setup)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

I’m hoping this issue will get some attention. There are not many AI coding tools that are accessible to blind people. Cursor is one of them - in general accessibility is pretty good. But this recent regression slows me down significantly.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report, and especially for calling out accessibility, that context matters.

This is a known bug on our side: Ctrl+L visually closes the chat, but it doesn’t restore focus to the editor. In editor-tab mode, the focus-restore logic just isn’t there. Ctrl+Shift+E gets stuck in the sidebar for a related reason, focusActiveEditorGroup via keybinding currently doesn’t fire correctly. We’re already tracking both issues internally.

I can’t share an ETA for a fix. If there’s an update, I’ll reply in the thread.

For now, a workaround is: Ctrl+P Quick Open plus the file name is usually faster than navigating via the file explorer, and focus lands directly in the editor. Not perfect, but fewer keystrokes than the current path.

If you find more a11y regressions, please post them, those reports are genuinely valuable.