Concern for screen reader users

[becka11y]

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

[snianu]

cc @BoCupp-Microsoft

[css-meeting-bot]

The Web Editing Working Group just discussed virtual-keyboard concern for screen reader users.

The full IRC log of that discussion

Topic: virtual-keyboard concern for screen reader users
github: https://github.com//issues/15
agenda+ Move meeting to Thursdays?
BoCupp: Will requires a bit of research...
.. we've tried to reproduce the problem
.. in theory you change the visual viewport and then auto scroll-into-view (default for some chromium platforms)... then the screen reader is unaware of the movement?
Action: BoCupp to investigate this report and report back with findings
a?

[css-meeting-bot]

The Web Editing Working Group just discussed Concern for screen readers.

The full IRC log of that discussion

Topic: Concern for screen readers
github: https://github.com//issues/15
BoCupp: Noticed my action here...
.. checking with anupam...
snianu: No conclusion yet... perhaps we can discuss today?
BoCupp: Haven't had any progress on this one. Will come back to it next month.

[css-meeting-bot]

The Web Editing Working Group just discussed concern for screen reader users.

The full IRC log of that discussion

Topic: concern for screen reader users
github: https://github.com//issues/15
johanneswilm: Last update: bo indicate no progress, will comeback next month? Can we discuss with without Bo present?
Travis: scanning the issue to try to understand.
Anupam: on iOS isn't the content overlaid?
whsieh: confirmed, yes that is what happens.
johanneswilm: on iOS/MacOS when a virtual keyboard is overlaying page content, does the screen reader treat the overlaid content as visible (e.g., "keyboard is visible"). Does Voiceover keep reading content underneath?
Action: whsieh to check with accessibility folks to see if screen readers continue reading content covered up by virtual keyboards? (Or similar overlays).
Travis: Had an opportunity to observe this behavior with screen reader users--it absolutely happens that screen readers keep reading what is underneath surprise popups (e.g., ads) that happen on popular pages all the time. (I'm not sure this is a new or unique problem.)
johanneswilm: was this what Bo was going to look into? Is this something the OS could address?
Anupam: not sure if the OS could address. In some cases OS is allowed to resize the content--other times, not so much.
johanneswilm: wondering is this is something that Firefox is concerned about?
annevk: I would suspect this would be resolved in the same way that IME resolves this issues.
... (IME for virtual keyboards). My brief assessment is that this should just fundamentally work.
.. I think we should ask for more details.
Action: ask @becka11y to help clarify the scenario in light of other things that can be occluded for screen readers.
johanneswilm: And that was the last topic!
end topic:

[johanneswilm]

@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?

[becka11y]

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.

[css-meeting-bot]

The Web Editing Working Group just discussed Concern for screen reader users.

The full IRC log of that discussion

topic: Concern for screen reader users
github: https://github.com//issues/15
johanneswilm: Is there an action for the group to discuss?
BoCupp: haven't had cycles to review this recently.
johanneswilm: reviewed the charter... (checking on timeline for standardization)
BoCupp: We plan to circle back on this in a bit, but haven't had a chance to look at it recently.