1854144 - Close (X) button is automatically focused when the "Are these reviews reliable?" callout appears

Status: RESOLVED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Peter Magyari (Desktop QA)]

Attachment: Screenshot 2023-09-21 at 15.53.46.png

Found in

• 119.0a1 (2023-09-20)

Affected versions

• 119.0a1 (2023-09-20)

Affected platforms

• All

Preconditions

• browser.shopping.experience2023.enabled- true

Steps to reproduce

1. Open Firefox and reach this link.
2. Click on the Yes, try it button inside the review checker sidebar.
3. Close the sidebar using the Address bar icon or the X close button.
4. Close Firefox.
5. Advance the date of your system by 1 day.
6. Re-open Firefox using the same profile and reach an amazon product page.

Expected result

• The "Are these reviews reliable? Find out fast." call-out pops out from the Address bar icon. The focus is not on the X close button.

Actual result

• The "Are these reviews reliable? Find out fast." call-out pop out from the Address bar icon is shown with focus set on the X close button.

Regression range

• Not a regression. The callouts were only recently added.

Additional note

• This does not occur on the other two callout types.

Comment 1

[Shane Hughes [:aminomancer]]

Callouts are traditionally supposed to have their calls to action focused when they appear, so I think the bug here is that it's not happening on callouts 1 and 3 the way it normally does. I'll investigate why that might be.

Comment 2

[Shane Hughes [:aminomancer]]

I think the button is focused for all 3 callouts, the focus just isn't visible (i.e. it doesn't draw a focus ring) in callouts 1 and 3 because it only does a visible focus if there was a visibly focused element when the callout opened. It does that to try to preserve the user's focus so that when the callout is dismissed, the previously focused element can be refocused as it was before. But if nothing was focused, it does an invisible focus instead.

To confirm, I'll ask product and UX whether we want the shopping callouts in particular to have this auto-focus behavior (it's not currently configurable but could be made so), and if the focus should always be visible or if it should continue to inherit the focus visibility from the currently focused element at the time the callout is opened. The reason we do that is because, if we always make the button focus visible, then when the callout is closed, the previously-focused element will be re-focused visibly just like the button was. But the previously-focused element may not have been visibly focused, which could appear like a bug. So the solution was to just keep the same focus visibility from start to finish. But that does mean the focus visibility is potentially inconsistent between the callouts, depending on what was focused when the callout first showed.

Ania and Yulia, do you have an opinion on those questions?

1. Should the shopping feature callouts be automatically focused? The original reason this was added to Feature Callout was for accessibility reasons. My understanding is it improves the screen reader experience.
2. If so, should the feature callout itself be focused (i.e. the popup box), or should the first interactive element inside the callout be focused (the dismiss button in this case - that's how it currently works)?
3. If so, should the focus always be visible (i.e. have a bright blue ring drawn around it)? Or should it try to preserve the focus visibility that was active before the callout opened, in order to consistently restore focus when the callout closes?

Thank you!

Comment 3

[Anna Yeddi [:ayeddi]]

BTW focusing the Close button is good for accessibility because it allows screen reader users to hear the callout information being announced and for keyboard-only users provides a quick way to dismiss the callout. Also, users with magnification software would get the callout into the viewport and thus would not miss it. I just recommended to move the focus to the Close button in the bug 1841374

Comment 4

[Shane Hughes [:aminomancer]]

The focus should already be on the Close button, as this behavior has been part of Feature Callout since its original implementation. Anna, can you confirm that is working correctly for you? If the Close button is not being focused for you, that would be a new regression.

Comment 5

[Anna Yeddi [:ayeddi]]

I have not received the callout yet, but I have not spent much time on Windows machine in the past few days. I'll try again later today or tomorrow, with a sparkling clean profile - and will report back

Comment 6

[Anna Yeddi [:ayeddi]]

adding a NI for myself to track the task

Comment 7

[Yulia Popova]

We had a quick chat in the UX team regarding this behavior. The way we think it should function: If the user has been navigating with a mouse, in this case the close button doesn't need visible focus outline in the callout. If the user using keyboard to navigate, in this case the close button in the callout would have a visible focus outline.

Comment 8

[Anna Yeddi [:ayeddi]]

(In reply to Shane Hughes [:aminomancer] from comment #4)

The focus should already be on the Close button, as this behavior has been part of Feature Callout since its original implementation. Anna, can you confirm that is working correctly for you? If the Close button is not being focused for you, that would be a new regression.

On today's Nightly Fx 120.a01 2023-10-12 the when keyboard was used to navigate to and activate Close button on the Onboarding sidebar, the OMC alert was shown, but the keyboard focus was not moved to the callout's Close button - the NVDA announced alert but needed to press Tab key once to move the focus on-screen and to the Close (the focus position was not visible when the callout was opened). I''l provide a screenshot with NVDA speech view output

Comment 9

[Anna Yeddi [:ayeddi]]

Attachment: NVDA_speech-output-when-sidebar-is-closed-and-popup-is-shown.png

Comment 10

[Ania]

Apologies for dropping the ball on this.
Anna, if the focus is on the callout itself rather than on the Close button, would that be an acceptable compromise? Will screen readers announce the contents of the callout in this case or would the user need to tab more than once?

Also, would it break any automations on your side if we dropped priority to P2?
It does not seem urgent to address in 119, and triggers the shiproom alert of an important bug detected :)

Comment 11

[Shane Hughes [:aminomancer]]

The logic for focusing the callout is the same as for focusing the close button, so there wouldn't really be any need to focus the callout instead. We already focus the close button, and we only focus the callout itself if no matching button is found in the callout. I've tried to reproduce this several times on Windows 10 and it works consistently for me. The only issue I can see is that the callout close button's focus outline is invisible even though the sidebar close button's focus outline was visible when I activated it. Maybe this is the same issue Anna is referring to, since if Firefox wasn't focusing the close button, Tabbing once would probably not reach the callout, but some element in the browser chrome.

Anyway for me, it is getting focused, just not visibly. That's a difficult issue to solve though. It basically tries to preserve the focus outline state, so if you had something visibly focused before the callout opened, then the callout (or an element inside it) will be visibly focused. Then when you close the callout, it should return focus to what you had focused before. The problem in this case is that the sidebar's close button disappears when you click it. And although it seems to happen immediately, there's time between closing the sidebar and the callout showing. So by the time the callout shows, you no longer have anything visibly focused. The sidebar's been totally deconstructed, so Firefox can't tell that you had a visible focus. The only straightforward workaround would be to make the focus visible for everyone. But that will cause a problem when we try to return focus after the callout closes: we won't know whether the previous focus was visible or not, so we'll have to assume it is or is not.

Comment 12

[Anna Yeddi [:ayeddi]]

(In reply to Ania from comment #10)

Apologies for dropping the ball on this.
Anna, if the focus is on the callout itself rather than on the Close button, would that be an acceptable compromise? Will screen readers announce the contents of the callout in this case or would the user need to tab more than once?

Also, would it break any automations on your side if we dropped priority to P2?
It does not seem urgent to address in 119, and triggers the shiproom alert of an important bug detected :)

It is an access-S4 and also the current behavior is acceptable = the NVDA does announce the callout information and only one Tab is needed to focus the dialog. Considering what Shane has shared above, it looks like with the technology that we have now, this is the best that we could do.

I do not think it has to be P1, but I appreciate the confirmation. Also, the bug initially was reported that focusing the Close button was an issue and it feels like it was resolved for both the visual design (no outline) and for a11y (the callout itself is focused). I'd vote for closing the bug as Fixed, since the initial issue has been fixed (without breaking an accessibility of the component) :)