1846572 - [Win] Focus order is chaotic when an NVDA user tries to use Up/Down Arrows to navigate a list of links

Status: VERIFIED FIXED

(Firefox :: Firefox View, defect, P1)

Description

[Anna Yeddi [:ayeddi]]

Attachment: 2023-07-31_Keyboard_with_NVDA.mp4

set browser.tabs.firefox-view-next to true

STR:

1. With NVDA running, navigate to View all using keyboard (Tab)
2. Navigate to the second link in the list by pressing Down Arrow only
3. Press Tab and then press Tab+Shift

Expected:

1. Focus visually would move to the second link when using Down Arrow
2. Pressing Tab would move the focus visually and programmatically to the next section (Recently closed tabs)
3. Pressing Shift+Tab would return the focus to the second link in the list of opened tabs

Actual:

1. Focus stays on View all visually, while pressing Enter would activate a link from the list below
2. When a second link is announced by NVDA, pressing Tab moves the programmatic and visual focus to the third link in the list
3. Pressing Shift+Tab moves the programmatic and visual focus to the first link in the list

The biggest concern here is that while keyboard-only users would use Arrow navigation for the list of links, screen reader users won't be able to move their focus visually, thus for sighted screen reader user like those with low vision or with dyslexia it would be confusing where the focus position is currently is and if the focus is moved and which control would be, in fact, activated should they press Enter now.

The sudden added focusability of some controls just makes this issue with the clarity of navigation more confusing.

Comment 1

[Anna Yeddi [:ayeddi]]

Attachment: NVDA-speech-viewer_shows_the_announcements_for_the_steps_described.png

Another example of this erratic behavior can be observed when a second column of controls is present. In this case, the Dismiss a recently closed tab buttons do not provide a screen reader acces by arrowing Right/Left when a screen reader is running:

1. A screen reader user would need to use the browsing mode (Up/Down arrows) to move through the multiple parts of the link (separate bug).
2. Then, when a button is focused in a browse mode (using Down/Up arrows for NVDA), it can be activated.
3. When the button is activated with Enter, the focus is visually landed on the Dismiss button for the next tab in the list, instead of the title of that next tab in the list (thus the title would not be announced and the link won't be known unless a user will Browse/arrow back)
   Refer to the screenshot attached for the NVDA output received while performing these steps above

Comment 2

[Anna Yeddi [:ayeddi]]

Attachment: Awesome-bar-example_with_NVDA_output.png

for example, the awesomebar ensures the Up/Down arrow navigation with the screen reader works as with the keyboard alone - the focus is moved visually and programmatically

Comment 3

[Anna Yeddi [:ayeddi]]

We discussed it with Jamie, and since the keyboard navigation alone is working very well, we'd recommend wrapping the whole View page in role=application - this would force screen readers to follow the arrow and tab navigation pattern that is handled well already by the page (screen readers like NVDA won't go in Browse mode that overwrites the arrow nav pattern and is currently buggy, but the user can escape the Forms/role=application mode too if they want to, so they are not locked out).

As always, happy to answer any questions and provide any further info

Comment 4

[James Teh [:Jamie]]

(In reply to Anna Yeddi [:ayeddi] from comment #3)

screen readers like NVDA won't go in Browse mode that overwrites the arrow nav pattern and is currently buggy

Just for clarity, the behaviour you're seeing is expected in browse mode; this is not a bug. Screen readers deliberately don't set focus when moving the browse mode cursor because setting focus can have unexpected side effects (including performance degradation) on modern websites. Note that alow vision NVDA user could enable various settings in NVDA menu -> Settings -> Vision to highlight when moving the browse mode cursor.

Having said that, given that this page implements keyboard navigation with cursor keys and given that the experience is superior with the native keyboard navigation, we think role="application" is appropriate here.

Comment 5

[Kelly Cochrane [:kcochrane]]

Attachment: Bug 1846572 - Adding role='application' to fix keyboard navigation in Firefox View with NVDA on Windows r=mkaply

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:kcochrane, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7d891879797e
Adding role='application' to fix keyboard navigation in Firefox View with NVDA on Windows r=mkaply,fluent-reviewers,ayeddi,flod

Comment 8

[Cristina Horotan [:chorotan]]

Backed out changeset 7d891879797e (Bug 1846572) for causing bc failures at browser_firefoxview_next.js

Backout: https://hg.mozilla.org/integration/autoland/rev/d89c15eac4ec564501a3193bdcd58be7d02393c5

Failure push: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=7d891879797eb2e69ac2fbf3d0c8a246c14e3281&selectedTaskRun=Bfcp86EgSKyGmwk4yVGIBw.0

Failure log: https://treeherder.mozilla.org/logviewer?job_id=426134092&repo=autoland&lineNumber=7786

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d36629c9f5b6
Adding role='application' to fix keyboard navigation in Firefox View with NVDA on Windows r=mkaply,fluent-reviewers,ayeddi,flod

Comment 10

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/d36629c9f5b6

Comment 11

[Ina Popescu, Desktop QA]

I've reproduced this issue using Nightly 118.0a1 (2023-08-01) following the STR from Comment 0 on Windows 10 x64 .
I've checked the keyboard navigation on Firefox View page, while having NVDA enabled, in latest Firefox 118.0b5 version and noticed following behavior:

• When using Down Arrow, the Focus stays on View all and the page is scrolled down
• Pressing Tab would move the focus to the first link in the the list of Open tabs
  At this point we are able to navigate to the second link from the list by using Down Arrow.
• Pressing Tab again would move the focus to next section Recently closed tabs
• Pressing Shift+Tab would return the focus to the second link in the list of Open tabs

Anna, is it OK that we have to use TAB to reach first link in the list of Open tabs?

Comment 12

[Ina Popescu, Desktop QA]

Attachment: keyboard navigation in FF 118.0b5.mp4

Comment 13

[Anna Yeddi [:ayeddi]]

(In reply to Ina Popescu, Desktop QA from comment #11)

I've reproduced this issue using Nightly 118.0a1 (2023-08-01) following the STR from Comment 0 on Windows 10 x64 .
I've checked the keyboard navigation on Firefox View page, while having NVDA enabled, in latest Firefox 118.0b5 version and noticed following behavior:

• When using Down Arrow, the Focus stays on View all and the page is scrolled down
• Pressing Tab would move the focus to the first link in the the list of Open tabs
  At this point we are able to navigate to the second link from the list by using Down Arrow.
• Pressing Tab again would move the focus to next section Recently closed tabs
• Pressing Shift+Tab would return the focus to the second link in the list of Open tabs

Anna, is it OK that we have to use TAB to reach first link in the list of Open tabs?

Thank you for testing the behavior now, Ina!

Yes, the Tab use is expected, because the main area of the Fx View now is an application and when the focus moves into it, the NVDA does announce application and beeps - this would signal to a screen reader user that they're in the focus mode where arrow keys are not expected to read next/previous line/letter similarly to when they enter a form or a textarea (vs. browsing mode that is activated by default on webpages). If they want to re-activate browsing mode and use Up/Down arrows, they could still do it with a shortcut.

That's being said, we could make an enhancement and move focus from View all to the first ... button under it, when Down arrow is pressed and back to View all on Up to improve the spacial navigation experience for signed keyboard NVDA users.

Comment 14

[Ina Popescu, Desktop QA]

(In reply to Anna Yeddi [:ayeddi] from comment #13)
Should I file a separate enhancement for this? Thanks.

That's being said, we could make an enhancement and move focus from View all to the first ... button under it, when Down arrow is pressed and back to View all on Up to improve the spacial navigation experience for signed keyboard NVDA users.

Comment 15

[Anna Yeddi [:ayeddi]]

(In reply to Ina Popescu, Desktop QA from comment #14)

(In reply to Anna Yeddi [:ayeddi] from comment #13)
Should I file a separate enhancement for this? Thanks.

That's being said, we could make an enhancement and move focus from View all to the first ... button under it, when Down arrow is pressed and back to View all on Up to improve the spacial navigation experience for signed keyboard NVDA users.

(apologies for the delay in reply, Ina)
Yes, please! Thank you a lot

It'd have keyword access and accessibility severity: s3 flag.

Comment 16

[Ina Popescu, Desktop QA]

(In reply to Anna Yeddi [:ayeddi] from comment #15)

(In reply to Ina Popescu, Desktop QA from comment #14)

(In reply to Anna Yeddi [:ayeddi] from comment #13)
Should I file a separate enhancement for this? Thanks.

That's being said, we could make an enhancement and move focus from View all to the first ... button under it, when Down arrow is pressed and back to View all on Up to improve the spacial navigation experience for signed keyboard NVDA users.

(apologies for the delay in reply, Ina)
Yes, please! Thank you a lot

It'd have keyword access and accessibility severity: s3 flag.

I've logged Bug 1855928 as enhancement.
Marking the current issue as VERIFIED FIXED.
Thanks.