[Accessibility] Make terminal a11y buffer even more accessible

[jooyoungseo]

CC @meganrogge @Tyriar @isidorn

I have tested the terminal a11y buffer by building the latest vscode main branch on my end.

Good news is that the buffer is now readable Thank you very much! I am sharing some suggestions along with bug reports.

• No clue on whether users have reached the end of the terminal buffer.

Say, you are navigating the a11y terminal buffer via UpArrow/DownArrow. When there are repetitive prompt line, such as "PS C:\Users\john>" screen reader users cannot easily understand whether they have reached the end of the buffer or that's just the repetitive prompt message.

I suggest VSCode team add audio cues to indicate the buffer's top/bottom ending points. Instead of making a new sound, I personally think a gentle chime audio cue like "Terminal Bell (Disabled)" could be used for this purpose.

• Terminal a11y buffer is not read-only.

Since this is contenteditable textbox, unintended delete key can mess up the output content. I confirmed that delete key works inside the buffer.

It would be even nicer if this buffer could be marked up with readonly to prevent users from accidentally deleting their output content.

• Terminal live output is not announced.

As far as I tested on Windows with JAWS and NVDA, terminal aria-live event is not auto-announced. I typed "echo hello" in terminal, but there was no read-aloud feedback.

• Ctrl+UpArrow/Ctrl+DownArrow still does not trigger line-by-line announcement.

This issue does not seem to be fixed on Windows.

[jooyoungseo]

I have confirmed that The report I shared above is also replicable with today's insiders:

Version: 1.75.0-insider (system setup)
Commit: f1b0923
Date: 2023-01-23T11:53:59.088Z
Electron: 19.1.9
Chromium: 102.0.5005.194
Node.js: 16.14.2
V8: 10.2.154.23-electron.0
OS: Windows_NT x64 10.0.22621
Sandboxed: Yes

[steverep]

I had filed a very similar report in #171833 and it was closed claiming to be fixed as part of #169853, which was not true at all.

I also find it kind of weird to be saying "even more accessible" here. As far as I can tell, insiders terminal a11y is now much worse to the point where I am reverting back to using 1.74.

[jooyoungseo]

The terminal buffer accessibility has improved by using the textbox view. However, what makes uses feel it worse are:

1. Ctrl+UpArrow and Ctrl+DownArrow (line-by-line) navigation does not work. yes, this is a critical bug and must be fixed.However, I would like to highlight that this inadvertent regression was already introduced before @meganrogge implemented this contenteditable buffer. This means there are other factors that had broken this feature.

2. Terminal real-time aria-live event does not work. This is also a critical bug that needs to be fixed asap. I did not experience this issue before this new a11y buffer so I assume that there was something breaking this aria-live.

[meganrogge]

Ctrl+UpArrow and Ctrl+DownArrow (line-by-line) navigation does not work. yes, this is a critical bug and must be fixed.However, I would like to highlight that this inadvertent regression was already introduced before @meganrogge implemented this contenteditable buffer. This means there are other factors that had broken this feature.

This is what we call "navigation mode" and we closed #166238 and #171833 because we believe this new buffer experience will be better than and replace that. Navigation mode has been broken for sometime and we aren't sure why - here's the upstream issue investigating that xtermjs/xterm.js#3247. Once this new mode is polished and bugs are ironed out, we can reassess to see if navigation mode is still needed.

[meganrogge]

I'm going to make separate issues from this one

[jooyoungseo]

@meganrogge

This is what we call "navigation mode" and we closed #166238 and #171833 because we believe this new buffer experience will be better than and replace that.

Yes, I understand. If VSCode team would end up replacing the conventional navigation mode with the new a11y buffer, please don't forget to take out the misleading message as highlighted by @pawin35 via #169853 comment:

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.

[meganrogge]

thanks, tracking that now in #172011 and #170988

[meganrogge]

Tracking everything in separate issues

[rmwilliams2023]

@meganrogge Apologies if this is the wrong place to ask, and perhaps I'm confused, but if navigation mode is not fixed, does that mean one can not scroll through the history of previously entered commands and rerun one simply by pressing enter on it? That would be very unfortunate from an efficiency point of view.

[meganrogge]

@rmwilliams2023 are you asking from a screen reader perspective? If so, it depends. Navigation mode is flaky atm, but for non-windows users, shell integration's Run Recent Command command can be used to navigate history. It does not work on windows atm for screen readers bc pwsh disables PSReadline, which we rely upon