-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Keyboard focus not set on browser by default #32
Comments
I managed to resolve this by calling the MoveFocus method of
I feel that, if the window is being created by the library as opposed to by the caller, as the browser will be the only thing in that window, it is the most accessible approach to have the library focus the browser by default. |
Also, an additional note: while I can get focus to reliably move into the browser when the window is initially created, I can't get it to stay there. If I Alt+Tab to another window and then back, focus lands on the window again. |
Sorry about this one. As far as I can tell, the most "correct" solution is simply make use of the very poorly named The default event loop has been adjusted to do exactly this. |
@jchv Thanks, this certainly fixes the case of not being able to Tab/Shift+Tab into the webview once created. But it is still desirable to:
Additionally, some of the problematic behaviour is still present, specifically:
If focus is inside the webview when the user switches away from the window, it should also still be there when they switch back. |
Understood. We can call MoveFocus on WM_ACTIVATE, which would probably accomplish what you are looking for. The change that was added is still useful since it allows us to have focus move from the window to the webview, if, for example, the user were to click the title bar explicitly. I'll take a look at it later today when I am off work and have a moment. |
@jchv Thanks, sounds good. |
It might be hard to fully resolve this issue, though at least it's a lot better than it was. I think the keyboard focus behavior should probably simply make sense by default, but for now I have put the new behavior behind an option, |
When creating a new webview in a new window, i.e. what the demo example does, keyboard focus is set on the overarching window, and not on the document object rendered by the webview. This means that keyboard access is not available. To reproduce:
Expected result: keyboard focus will be handled by the webview, and move through the focusable elements on the page.
Actual result: nothing happens.
This is a significant issue for accessibility. Not only does it prevent keyboard-only users accessing apps built with this library (or ones based on it), it also means that screen reader software is unable to access the webview's content, unless the user can work out how to manually set focus on the document (e.g. using the Win32 API).
The text was updated successfully, but these errors were encountered: