Description
As of writing, the contents of the WebView2 control in the Win32_GettingStarted sample are not interactable using keyboard-only and cannot be read at all using Narrator. I tested this against the sample as of commit fc1269e, as well as the same sample with the current-as-of-writing version of the Microsoft.Web.WebView2 package (1.0.1418.22).
I don't expect the "Getting Started" sample to demonstrate robust cross-control keyboard interactions like the more detailed samples, but it should have sufficient keyboard and screen reader support to provide a comparable experience as a sample to keyboard-only users and to screen reader users.
Repro steps:
(tested on winver 22H2 22621.674)
- Clone repo and open
/GettingStartedGuides/Win32_GettingStarted/WebView2GettingStarted.sln
in Visual Studio - Start Narrator
- Build the project (in either debug or release mode) and run without debugger attached
Expected:
- I should be able to use tab/etc to manipulate the resulting dialog/page, without using a mouse, both at initial launch and after deactivating/reactivating the sample's window
- Narrator should be able to announce the dialog/page when navigated with a keyboard
- Narrator should be able to announce web controls on the page when clicking on them with a mouse
Observed:
- Keyboard controls do not get processed by the WebView2 unless/until the user first clicks inside the WebView2
- Narrator does not announce anything by default, in response to keyboard controls, or when the window receives focus
- If I click within the initial alert dialog, Narrator can announce the dialog, but once the dialog is dismissed, Narrator never announces the page, even if I click within the page and move keyboard focus around the page
Analysis
I think the root cause of this is that the sample does not include any provision for moving focus into the WebView2 control. I tested two candidate options for minimal sample updates that both resulted in more reasonable keyboard/Narrator behavior:
- Update the "main message loop" section at the bottom of
WinMain
to include anIsDialogMessage
check such that the WebView handles the necessary window activation/tab keyboard events on its own:
if (!IsDialogMessage(GetAncestor(msg.hwnd, GA_ROOT), &msg)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
- Update
WndProc
to explicitly invokewebviewcontroller->MoveFocus
in response toWM_ACTIVATE
events:
case WM_ACTIVATE:
if (webviewController != nullptr) {
webviewController->MoveFocus(COREWEBVIEW2_MOVE_FOCUS_REASON_PROGRAMMATIC);
}
break;
I think both of these are simple enough to be reasonable inclusions in the "Getting Started" sample. I think the latter is a marginally better screen reader experience for an app that truly is an empty wrapper around the webview and has no other focusable component, but I think the former is probably a better starting point for most readers of the sample in practice, so I'd recommend the former for the purposes of the "Getting Started" sample.