A11y: windows terminal emits selection/deselection events in mark mode when navigating with arrow keys

[beqabeqa473]

Windows Terminal version

1.15.1862.0

Windows build number

10.0.19044.1766

Other Software

• Narrator
• NVDA latest version

Steps to reproduce

• Run Narrator on NVDA;
• Open Windows terminal;
• Go to mark mode with ctrl+shift+m;
• Navigate text with arrow keys.

Expected Behavior

Screen readers should announce only characters when navigating with arrow keys.

Actual Behavior

Screen readers announce selection of the current char plus unselection of previous char in addition with current char announcement

[codeofdusk]

CC @carlos-zamora.

[carlos-zamora]

Hmm... This seems to be operating as expected. When you enter mark mode we create a single-cell selection at the current cursor position. The arrow keys then move that single-cell selection as described in the docs. Since we're selecting an adjacent character and unselecting the one we were just on, everything seems to be working as expected.

That said, we do want to get rid of that single-cell selection and instead move the cursor (just like in conhost). It's doable, but it requires a bit of refactoring under the hood. Doing so would require...

• selections to be stored as an inclusive start and an exclusive end (similar to how UIA handles it). Currently they're stored as inclusive start and end.
• ensure we differentiate between no selection and an empty selection (particularly important when copying text and calling IsSelectionActive)
• (from the UIA text provider side) GetSelection() needs to be able to get any of the following: (1) the selected range, (2) an empty selection exposed as the cursor, and (3) the cursor when no selection exists. We already do (1) and (3). (2) just requires us to be careful the previous point.

I'll chat about it with Dustin today to create a game plan here.

[beqabeqa473]

It needs a refactor indeed, because in a way how it is working now it is not so comfortable to use this feature.

[carlos-zamora]

Since this is a decent size change, we probably won't service this to 1.15, so I'm removing it from the servicing pipeline.
That said, I'll be working to fix this up to work as expected. Currently scheduled for 1.16 (next release).

[carlos-zamora]

For reference, doing this fix is a huge step towards #5099, so that's nice.

[beqabeqa473]

I understand development pipeline and it is of course sadly, that we won't see this fix in 1.15 series, but it is good that it will be fixed in the next release.

[beqabeqa473]

@carlos-zamora are there any news in this area?

[carlos-zamora]

Not yet, sorry. As I've mentioned before, it's a pretty big and risky change (though I get it's a really important one). We'll be having some planning meetings relatively soon, so I'll be sure this is a part of that so we can get a more accurate ETA. For now, I've moved it to the 1.20 milestone.

FYI, we do want to lump a lot of the accessibility work together, so this'll be a part of that discussion, for sure. Not a matter of if we'll do it, just a matter of when. We'll post updates on this issue as the plan becomes more clear though, so don't worry about being left out of the loop 😊