1896862 - The Weather Widget is the last element being focused using the keyboard navigation

Status: RESOLVED WORKSFORME

(Firefox :: New Tab Page, defect)

Description

[Alice Varro [avarro], Ecosystem QA]

[Affected versions]:

• Firefox build version: Firefox Beta 127.0b1, Build ID: 20240513155137

[Affected Platforms]:

• Windows 11 x64
• macOS Ventura 13.6.1
• Linux Mint 21.1

[Prerequisites]:

• Have an en-US Firefox build installed and opened.
• Have a VPN solution connected to the US.
• Have a stable internet connection to receive weather data.
• Have the "browser.newtabpage.activity-stream.showWeather" and the "browser.newtabpage.activity-stream.system.showWeather" prefs set to true.

[Steps to reproduce]:

1. Open a New Tab page.
2. Focus on each element using the Tab key until the Weather widget is focused.
3. Observe the behavior.

[Expected result]:

• The Weather widget is focused after the Personalize New tab menu is focused using the keyboard navigation.

[Actual result]:

• The Weather widget is the last element being focused on the New Tab page using the keyboard navigation.

[Notes]:

• We believe that this behavior would be more appropriate since the Weather widget is displayed on top of the page and since this is a new feature it would be more useful for users to reach the Weather widget faster using the keyboard navigation.

Comment 1

[Anna Yeddi [:ayeddi]]

The HTML tags were used perfectly here and the role of the feature is communicated programmatically, as expected.

The programmatic and visual reading orders are not matching is an actual access-S3 issue: unconsidered focus order.

While asides technically could be included in the focus order at the end, the question here is why did we put this element in the visual reading order before the main content. There’s probably a reason, visual design included. If it’s secondary and we want users to get to it only at the end of the page, maybe we should place it visually there too (at the end).

General rule of thumb is for the UI and tab order to match - for the focus order to follow the reading order (visual reading order for the locale to be followed by the DOM order of elements), reading order should be the same both programmatically and visually. It would allow for an equitable experience for users with and without assistive technology. A use case would be a screen reader user with dyslexia who can visually follow the screen reader’s focus and can see the visual position of elements. For them it’s likely to be confusing trying to read content first skipping its part, then jumping back up from the bottom of the page.

I recommend to change the type of this ticket to bug. Let me know if I can be of assistance with resolving it.

Comment 2

[Anna Yeddi [:ayeddi]]

Oops, didn’t mean to close it. Apologies for it

Comment 3

[Alice Varro [avarro], Ecosystem QA]

Thanks a lot Anna for all the explanations! I'll change the type of this ticket to bug in this case.

Comment 4

[Maxx Crawford [:maxx]]

Solved during the fix for another work stream to resolve a CSS overlap issue.