1996822 - [macOS][Voiceover} Cannot reach the Weather opt-in callout with Voiceover controls

Status: VERIFIED FIXED

(Firefox :: New Tab Page, defect)

Description

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Found in

• Nightly 146.0a1 (2025-10-28)

Affected versions

• Nightly 146.0a1 (2025-10-28)

Affected platforms

• macOS 26.0.1

Preconditions

• browser.newtabpage.activity-stream.system.showWeather - true
• browser.search.region - Any EU opt-in regions (DE, FR, IT, RO, etc)

Steps to reproduce

1. Enable macOS Voiceover
2. Use voiceover commands to reach the Weather opt in Callout on the new tab.

Expected result

• The user can interact with the callout via Voiceover commands

Actual result

• The user cannot interact with the callout via Voiceover Commands

Regression range

• New feature

Additional Notes

• The issue can be seen in the following attachment
• Despite being unable to get to the callout via Voiceover commands, normal tabbing through items in newtab page works as expected, including interacting with the Weather Callout

Comment 1

[Reem Hamoui]

I'm unable to replicate this bug, as VoiceOver is interacting with the weather opt-in feature just fine. I've attached a screen recording

Comment 2

[Reem Hamoui]

Attachment: Screen Recording 2025-11-06 at 4.26.05 PM.mov

Screenrecording of VoiceOver interactive with Weather opt-in dialog

Comment 3

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Hey Reem, I can still reproduce the issue by using the specific VO commands (control+option+arrow keys) on Firefox 146.0a1 (2025-11-05). Are you using the same VO commands or simply tabbing through? (as tab and shift+tab will work fine, as mentioned in Additional Notes). Thanks!

Comment 4

[Reem Hamoui]

Hm okay I see what you mean now. Seems like this is happening with the weather widget overall and not just the opt-in dialog. When I try using the VO commands (ctrl+opt+arrow) when on the weather widget, it doesn't go to any other element on the page, it essentially halts VO navigation, and unless i explicitly press tab to go to the next section, it'll be stuck.
I'm going to deep dive a little more here today and see what I can do.

To note, if the weather widget is off, new tab doesn't face this issue. It's only when the weather widget is enabled

Comment 5

[Reem Hamoui]

I've reached out to the Accessibility team on Slack to get some help here, as I couldn't really narrow down why this is happening. I'll update this ticket once I know more

Comment 6

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

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Morgan Reschenberg [:morgan]]

(In reply to Reem Hamoui from comment #5)

I've reached out to the Accessibility team on Slack to get some help here, as I couldn't really narrow down why this is happening. I'll update this ticket once I know more

Hi Reem, I dug into this a bit more and wanted to provide ya some additional info:

First, I can reach the weather widget using VO controls, but I cannot reach the rest of the new tab content. I think this matches your experience but it is a bit different than what was initially reported in #c0 so I wanna verify.
I can also reach the widget's three-dot menu and the expand-devtools link.
However, when I reach the end of the navigation I just get looped back to the top level tab document, and I never reach the new tab content. My navigation looks like this:

focus top level tab document for about:newtab
VO + shift + down to enter content
VO focuses "Expand Devtools" link
VO + right arrow to go next
VO focuses weather widget
VO + right arrow to go next
VO focuses weather widget's three dot menu
VO + right arrow to go next
VO focuses top level tab document, if I press VO+shift+down to enter, I repeat the navigation above starting at the "expand devtools" link.

Initially I thought the issue here might be the weather widget's placement in the DOM, as it is located outside of the "main" element. When I use the macOS accessibility inspector to show the tree that VoiceOver uses, I see the following:

NewTab HTML document

Group

Link - 54 degrees, San Francisco, Sunny (with 3 children, groups, for each text element inside of the widget)
Link - Expand Devtools
Link - 54 degrees, San Francisco, Sunny
Menu button - Open Menu
Group - unnamed (This is where the main content lives, which we can't reach using VO navigation).
Content List - unnamed

This tree seems wrong... why are there two links for the same weather widget? :o

I do not see this duplication in DOM, so I think the issue lies in the accessibility code (accessible/mac/) and not in anything you've written :)
That said, I wanted to check with you since you definitely know the newtab code better than I do: can you think of any reason VO might be seeing the link node twice? Are there any DOM relationships or references that might cause this kind of confusion?

Thanks for your help :)

Comment 8

[Morgan Reschenberg [:morgan]]

Hmm, I think this is a bug in the inspector actually :( when I probe the tree via other tools, it comes back with only one link accessible. Nevermind !

Still, you might be able to fix this by co-locating the widget and the <main> region of the page's content. I'm not sure why VO would fail as-is, the tree is in good shape.

Comment 9

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1996822: Expose weather data attribution as aria-description, hide text node from screen readers r?reemhamz

Comment 10

[Morgan Reschenberg [:morgan]]

oh boy this was hard to track down!
the core issue here is that the attribution text (AccuWeather * Sponsored, on my machine) is shown and hidden based on focus inside the weatherCard container. This text is focusable by VoiceOver, even though it isn't focusable to keyboard users.

When a VO user lands on the weather widget, the attribution text is shown and VO thinks "great, I'm going there when the user presses VO+next". But! when the user presses VO next, focus leaves the weather card and the text disappears (this is because the visibility is managed using :focus-within on .weatherCard which is a sibling of the attribution text, not the parent of it). This sends VO looking for a node that has since been deconstructed :( in cases like this, VO focuses the web area as a back up.

I think this text doesn't need to be reachable by screen reader users, and its size/location are indicative of a "description", so I've reused the l10n string and bound it to aria-description instead. I've also hidden the text node from screen readers with aria-hidden.

In the future, we should strive to have text always visible as much as we can; it maintains consistency which helps sighted users and it prevents issues like this one for ATs.

Comment 11

[Reem Hamoui]

Ahhhh this is such a fantastic find, great work!
I didn't even think to assume that was the case. I was mainly concerned with semantic elements and their placement in the DOM.
This is great information to know, and thank you for also taking the time to explain this so easily.
I'm glad to be one step closer to fixing this issue.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/822e5c305225
https://hg.mozilla.org/integration/autoland/rev/fd268a491766
Expose weather data attribution as aria-description, hide text node from screen readers r=reemhamz,fluent-reviewers,home-newtab-reviewers,bolsson

Comment 13

[Iulian Moraru]

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

Comment 14

[Catalin Sasca, Desktop Test Engineering [:csasca]]

I can confirm that the VO commands work as expected on Firefox 149.0a1 (2025-01-22) on macOS 26.2.