[Windows][a11y] Pressing the "down arrow" does not move the focus and read the Text Widget

[cbracken]

Internal: b/241886719

Scaffold(
      appBar: AppBar(
        // Here we take the value from the MyHomePage object that was created by
        // the App.build method, and use it to set our appbar title.
        // We also apply a custom font, ProductSans.
        title: Text(widget.title),
      ),
      body: Column(
        children: [
          Expanded(
            child: ListView(
              children: [
                Text(
                  'This 0',
                ),
                Text(
                  'This 1',
                ),
                Text(
                  'This 2',
                ),
                Text(
                  'This 3',
                ),
              ],
            ),
          ),
        ],
      ),
    );

Repro steps:

1. Run NVDA or any other screen reader on the windows machine.
2. Press tab to move the focus.

Actual: Not moving the focus to text and not reading it out.
Expected: Should move the focus to the text and read out loud.

[cbracken]

This is queued up next after #109802.

[Hixie]

@yaakovschectman informs me this is currently blocked on them getting some information from an a11y expert.

[chunhtai]

we have shortcut that handles tab on the framework side, we should first make sure it does not swallow the key press.
Is this a a keyboard focus or a11y focus? If we really can't get it to work, is it possible to send a11y focus event to the next item when tab is pressed?

[yaakovschectman]

In reality, we have found TAB works in a manner consistent with other applications, but keyboard commands that should allow navigation when using a screen reader (e.g. INS+UP/DOWN for NVDA) do not. Additionally, I have found that when using a screen reader, the screen reader processes keystrokes before Flutter does, so issues of Flutter swallowing key presses seem implausible.

[cbracken]

Depending on how soon you expect to be able to talk to the person we discussed on Chromium, one other option is that NVDA is open source (appears to be written in python) so it may be possible to instrument it to get a better picture of what's going on.

[Hixie]

update: @yaakovschectman informs me that they are talking with someone from Chrome about this.

[cbracken]

Swapping assignment to myself while I attempt to clarify this bug and locate some win a11y experts who can help define the expected behaviour here.

The current state is:

• NVDA documents that the Tab key reads the next focusable item such as (e.g. links, buttons). Text widgets are not focusable items and therefore our behaviour with regards to the Tab key is, I believe, working as intended.
• NVDA documents that the down arrow key reads the next item. When I reconstruct the same example as HTML in a web browser, the down arrow does read each item in turn. In Flutter, it does not. Therefore, I think there is a bug to be resolved here. I'm following up with the internal filer on that side of things.

[chunhtai]

I am seeing a weird reporting from the customer see https://buganizer.corp.google.com/issues/245911732#comment18

In the workaround i asked customer to exclude the semantic of a link widget. so the semantics tree should not have the link widget included. The customer reported they can still use tab to traverse to the link widget that got excluded. It seemed to me that the tab is not using the semantics tree to find the next focus, it probably go through a different system, which is likely going through the flutter shortcut system

[jacobsimionato]

Just wondering if there have been any updates on this issue recently? I'm eager to unblock our Google customer!

[cbracken]

We're still investigating what's going on with the arrow key navigation. @yaakovschectman has confirmed that NVDA is getting the keypress before the Flutter embedder is. Given NVDA is open source, I'm having a look at whether I can debug from the NVDA side to reveal what's going on here.

[yaakovschectman]

I spoke with somebody from NVDA, and it turns out that the functionality of the arrow keys is not modified by NVDA screen reader. The arrow keys are handled by an app as they normally are, and the app may fire an event in response. NVDA object navigation can be used to navigate through non-focusable elements, which sounds like what this issue regards.

[flutter-triage-bot]

This issue is marked P1 but has had no recent status updates.

The P1 label indicates high-priority issues that are at the top of the work list. This is the highest priority level a bug can have if it isn't affecting a top-tier customer or breaking the build. Bugs marked P1 are generally actively being worked on unless the assignee is dealing with a P0 bug (or another P1 bug). Issues at this level should be resolved in a matter of months and should have monthly updates on GitHub.

Please consider where this bug really falls in our current priorities, and label it or assign it accordingly. This allows people to have a clearer picture of what work is actually planned. Thanks!