Open becka11y opened 2 years ago
cc @BoCupp-Microsoft
The Web Editing Working Group just discussed virtual-keyboard concern for screen reader users
.
The Web Editing Working Group just discussed Concern for screen readers
.
The Web Editing Working Group just discussed concern for screen reader users
.
@becka11y Hey, we were discussing this issue today. We recognize that this can be a problem, but we wonder if this issue is only happening with the virtual keyboard or whether this also happens with other things overlaying the browser window - for example IME, or a select drop down or a popup or something else? If it is a general issue that applies to different kinds of things that can cause the the content to be hidden, maybe it would make most sense to put it in a more general spec that is not specific to only the virtual keyboard?
Generally, with a select dropdown or dialog the focus is trapped within that component until the user finishes interacting with the component. The user would not encounter any information "underneath" the content. You raise a good point about a popup, that may not trap focus but remain on the screen until the user interacts with another component. My concern with the virtual keyboard is that it may be more permanent on the screen. Ideally it would only be visible when the user is interacting with a control that needs input OR any content behind the keyboard would scroll to become visible as the user navigates. This would be necessary for all users, not just those using a screen reader.
The Web Editing Working Group just discussed Concern for screen reader users
.
I reviewed this document on behalf of the Accessible Platform Architectures (APA) working group. I have possible concerns of confusion for screen reader users.
This comment in issue #5 resonated with me: "I'm a little lost as to whether VisualViewport is intended to account for whether or not the virtual keyboard is overlaying page content or not - to me it reads as if it assumes the keyboard is overlaying page content, since otherwise it will be the same as the layout viewport."
Screen readers can pull the entire DOM into a virtual buffer to allow a user to navigate line by line. My concern is that if the virtual keyboard is overlaying page content, the screen reader user can potentially navigate "behind" the virtual keyboard. There are screen reader users who are also sighted and hearing information that is not visible can be confusing to them. I believe that the keyboard would only be visible when an item needing input has focus. However, the screen reader user can change modes from forms mode, interacting with a focused control, and browse mode, interacting in DOM order using screen reader commands. My concern is that if the virtual keyboard is overlaying the content, it could pose problems for screen reader users. Hopefully my concern is just do to my less than thorough understanding of the nuances of this API