conhost: Make screen readers announce search results

[Carlos Zamora (carlos-zamora)]

Summary of the Pull Request

Fixes a bug in console host where search results weren't being announced by the screen reader.

Adds 2 localized resources for announcements:

• ID_CONSOLE_MSGFINDRESULT: "%1!d! of %2!d!"
• ID_CONSOLE_MSGFINDNORESULT: "No results"

Updates the AccessibilityNotifier with a new AnnounceSearchResults() which handles making the announcements above using UiaRaiseNotificationEvent() (similar to how we make similar announcements in Windows Terminal).

The user experience itself is similar to Windows Terminal. The main difference being that Terminal announces the selection state after closing the search box (" selected"), and console host does not.

References and Relevant Issues

⚠️#20152: the off-by-1 error effects search results in this branch

Validation Steps Performed

Opened the search box and performed a search with...
✅ results --> "<1-indexed num> of "
✅no results --> "no results"

PR Checklist

Closes https://dev.azure.com/microsoft/OS/_workitems/edit/37170192/?view=edit

[Carlos Zamora (carlos-zamora)]

Ok. I've been trying to replicate the UX from Windows Terminal. Here's my findings.

Windows Terminal UX

Steps:

• Open search box
• Type a query, press Enter
• Announcement: "x of n"
• Close search box
• Announcement: "X selected"

Using Narrator results in the experience described above. Using NVDA, however, DOES NOT. Specifically, NVDA suppresses the announcements due to nvaccess/nvda#13261.

Conhost UX

• Open search box
• Type a query, press Enter
• Announcement: "x of n"
• Close search box

Using Narrator results in the experience described above. The tricky part here is that we're missing the "X selected" announcement after we close the search box. From some testing and investigation, it looks like the issue is that the Find dialog has its own HWND, so it suppresses the UIA events from the underlying terminal control.

Narrator does have some weird behavior here too. Specifically, consider these two cases before the find dialog is opened:

1. no selection exists
   • When the dialog closes, we hear "Text area, editing" even though the queried text is selected!
   • The user can use mark mode key bindings like Shift+Right to modify the selection, and in those cases, the selection is modified and the delta is announced appropriately (i.e. "e selected").
2. a selection exists (i.e. "foo")
   • When the dialog closes, we hear "Text area, editing; foo selected" even though the queried text is selected!
     I'm particularly bothered by this scenario. There's more details on this in a separate section below.

Normally, the way that last "X selected" announcement is made is not through a UIA notification, but actually a simple UIA Text_TextSelectionChanged event. Terminal/Conhost just tell the attached screen reader that our text selection changed, but not how (standard), and the work is on the screen reader to perform a diff and make the appropriate announcement. What makes it a little more complicated is that the same event is used for cursor changes too, but that's more of an FYI than anything.

UX when using NVDA

As mentioned above, NVDA suppresses UIA notifications from conhost and Terminal due to nvaccess/nvda#13261. As such, the approach of using UIA notifications as a whole doesn't work, full stop. That said, this is consistent across both terminals, so I think that's ok. If they want to opt-in to the new notification, it will require changes on their side, and I think that's fair (though I'm open to feedback here).

Adding the missing "X selected" announcement in Conhost when using Narrator

We're able to "fake it" using a UIA notification with a simple "<text> selected". We could add a similar AccessibilityNotifier::AnounceSelection(std::wstring_view text) which synchronously performs the announcement. Aside from that, we really just need to extract the selected text after closing the find dialog and hand it over to this new AnnounceSelection() function.

When no selection exists before opening the find dialog, this works as expected and fixes the issue! Upon closing the find dialog, you'll hear a "Text area, editing; <text> selected".

However, if a selection did exist on, for example, "foo", we hear "Text area, editing; <text> selected"; foo selected. To be honest, I'm not sure why Narrator announces the old selection. That already is pre-existing behavior though, so arguably it's a bug on Narrator.

The fix is stashed on my machine at home. It's pretty small and easy, but I want to make sure this is an approach we want before committing it.

CC Dustin L. Howett (@DHowett) Bill Dengler (@codeofdusk)