Explore plain content editable element for terminal buffer instead of navigation mode

[Tyriar]

Prototype: xtermjs/xterm.js#4340

[meganrogge]

Shift tab appears to list things with oh-my-zsh.

shift-tab.mov

[Tyriar]

@meganrogge oh you're right, it does go to the shell. In that case I'd special case that in a11y mode here:

vscode/src/vs/workbench/contrib/terminal/browser/terminalInstance.ts

Lines 1022 to 1037 in b535afb

	// If tab focus mode is on, tab is not passed to the terminal
	if (TabFocus.getTabFocusMode() && event.keyCode === 9) {
	return false;
	}
	// Always have alt+F4 skip the terminal on Windows and allow it to be handled by the
	// system
	if (isWindows && event.altKey && event.key === 'F4' && !event.ctrlKey) {
	return false;
	}
	// Fallback to force ctrl+v to paste on browsers that do not support
	// navigator.clipboard.readText
	if (!BrowserFeatures.clipboard.readText && event.key === 'v' && event.ctrlKey) {
	return false;
	}

Tab focus mode can be toggled to use it otherwise

[meganrogge]

@jooyoungseo it would be great if you could test this in tomorrow's insider's

[jooyoungseo]

@meganrogge -- Unfortunately, doesn't work tested with today's insiders.

1. NVDA (also JAWS) does not read line-by-line terminal output via Ctrl+ArrowUp / Ctrl+ArrowDown when invoked in terminal input area.

2. The accessibility terminal buffer (output) area is not readable via standard arrow-key navigation (tested with both NVDA and JAWS): When you test this, you need to use "Focus Mode" for NVDA and "Forms Mode (AKA virtual cursor off status)" for JAWS. This is because this output buffer needs to be treated as a text area-style element.

3. In terminal input area, a message shows:

Terminal 1, cmdPress alt+f1 for terminal accessibility help Use Ctrl+UpArrow and Ctrl+DownArrow to navigate the terminal buffer.

However, pressing Alt+F1 does not open up any terminal-specific help menu. Alt+F1 works only when in a11y terminal buffer (output) area, but this help menu seems like the existing general a11y menu rather than terminal-specific a11y guide.

[rmwilliams2023]

@meganrogge I can confirm @jooyoungseo 's comments here, using latest release builds of JAWS and NVDA.

[meganrogge]

@jooyoungseo @rmwilliams2023 I will try on Windows, but all of the above is working for me on mac.

[meganrogge]

I see that on Windows Alt+f1 does not work - you should be able to run the command Terminal: Show Accessibility Help though. I will fix that, thanks for letting me know.

I can reproduce on Windows not being able to navigate via cursor. I am surprised by this as it's a content editable, which works on mac. @jooyoungseo what do you mean by treated as a text area-style element?

[jooyoungseo]

@meganrogge What I meant by textarea-style element is the contenteditable area, in theory, is a text area where standard cursor navigation works via arrow keys. I recommended you turn off screen readers' invisible virtual buffer, such as NVDA's browse mode or JAWS' virtual cursor, when testing this area. Otherwise, screen readers' arrow navigation keys would interrupt the native contenteditable cursor navigation.

[jooyoungseo]

@meganrogge -- The most accessible and screen-reader-friendly textarea view in VSCode worth testing is workbench.action.output.

You know, you can press Ctrl+Shift+U to trigger workbench.action.output.toggleOutput which is a textarea having role = "textbox". This view is very accessible to screen readers! I was expecting that the terminal a11y buffer would behave something like this.

[jooyoungseo]

@meganrogge For the same reason, when testing any text editor area with VoiceOver, the QuickNav needs to be turned off.

[meganrogge]

Okay thanks for the info, I'll look into this today

[meganrogge]

I went with a textarea like you suggested @jooyounseo. I did not see any perf issues despite testing with 1000+ lines on windows and macOS, but think that could be one issue with this approach.

@Tyriar was telling me that Chromium has a new feature that lets one place a cursor at any position, so when we adopt that, we might revert to the div instead.

[steverep]

@meganrogge the issues I mentioned in #171833 are still unresolved as of today's build. The only thing that seems to have changed is that I now get feedback while typing commands. However, ALT+F1 and CTRL+Up/Down seem to do nothing, and command output is no longer spoken. I'm on Windows 10 with NVDA.

[pawin35]

I have tested the VS code insider with the new accessibility support for terminal and have found out the followings:

• The accessibility buffer do not work with NVDA with focus mode set to on (Arrowing up and down on the buffer do not provide any speech output)
• When switching to browse mode, the text can be read. (However, this is not the effective mode to use with VS code)
• When typing command that return an output on screen (such as echo "hello"), the displayed result do not auto-read by screen reader
• Since we do not use ctrl+up and down arrow anymore, the hint to use ctrl+up and down arrow to navigate should be removed.

[steverep]

This issue seems far from resolved. Please reopen.

[meganrogge]

The issue with the mode on Windows will be resolved in the next insider's build, which will be available tomorrow. Will create other issues to track those separately

[jooyoungseo]

The up-to-date accessibility report for this terminal patch has been filed via #171914.