1854153 - The X Close buttons from the Review Checker Address bar callouts are not read out loud by NVDA on hover

Status: NEW

(Firefox :: Messaging System, defect, P3)

Description

[Rares Doghi, Desktop QA]

Found in

• Nightly 119.0a1 (2023-09-20)

Affected versions

• Nightly 119.0a1 (2023-09-20)

Affected platforms

• Windows

Preconditions:
Set the browser.shopping.experience2023.enabled - TRUE
Set the browser.shopping.experience2023.optedIn - 0/1
Enable NVDA.

Steps to reproduce

1. Reach https://www.amazon.com/dp/B0BN3W4SQQ/ref=sbl_dpx_office-desks_B09L1KY91X_0?th=1
2. Close the Shopping sidebar.
3. Hover the Mouse cursor on top of the X Close button from the Addres bar callout.

Expected result

• The X Close button from each Callout should be read out loud by NVDA when hovered over.

Actual result

• The X Close buttons are not read by NVDA when hovered over.

Regression range
Not Applicable

Comment 1

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

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

For more information, please visit BugBot documentation.

Comment 2

[Anna Yeddi [:ayeddi]]

After finally being able to catch the callout with the NVDA running, it does appears to be that this is the NVDA behavior when it is not announcing image buttons (refer to my comment in a similar Shopping bug 1851735), but the button itself is properly labeled and is announced by NVDA as Close, button when focused with a keyboard (at the moment, you have to click on the callout and then press Tab to hear it though, per this discussion in callout bug 1841374)

Thus lowering the a11y-severity to S3, because while the button is not unlabeled (the user would know the purpose of this control, if they navigate there with a keyboard or access it via the screen reader-provided list of buttons), but we still could try to use an image with alt text - this seems to resolve the issue and hovered image button provides expected label announcement, i.e. in the following test case (CSS-provided images are ignored by screen readers vs HTML elements): data:text/html,<div id="1">How we determine review quality?%20%20%20%20%20 <button style="height:3rem;width:3rem;" aria-labelledby="1"></button>%20 </div><p>something else</p><button ><img src="https://cdn.iconscout.com/icon/free/png-256/free-touch-134-444304.png" alt="Label from image"></button>

I think we could keep the bug, but adjust it so the button's hover behavior is improved on the callout component level, but it is not an accessibility blocker for the release.

What do you think, Shane and Rares?

Comment 3

[Anna Yeddi [:ayeddi]]

Tagging you, Shane, since the solution above could be included in the tooltip improvement discussed in the bug 1854279

Comment 4

[Rares Doghi, Desktop QA]

I think that 2nd example when it reads "label from image" on hover would be perfect for the X Close buttons from the Shopping sidebar as well as the X close buttons from the Callouts. Having the NVDA read out loud Close button on hover without reaching it using keyboard navigation would improve the experience. I realize its an NVDA issue but it would be great to have this.

Comment 5

[Shane Hughes [:aminomancer]]

Isn't this the case with all the buttons in Firefox? None of the buttons in Firefox's toolbar have alt text. They have inner text (hidden by display mode), a label attribute, and in some cases a tooltiptext attribute (equivalent to HTML's title attribute). NVDA seems to read both the text content and the tooltip text on hover. Does anyone know how that works? I've tried replicating it but it doesn't seem to work in HTML. I would really like to avoid using an img element if possible, as it will cause NVDA to perceive two boxes, one smaller box for the img and one larger box for the button itself (and the larger box will not read "Close" on hover, since it's the img that NVDA actually reads in that case).

By the way, I'm curious about the requirement you mentioned about needing to click the callout and hit Tab. This seems strange because the callout is automatically focused when it shows. The dismiss button should already be focused as soon as the callout is visible. For me, it is focusing itself immediately and reading button Close.

Comment 6

[Shane Hughes [:aminomancer]]

Here's what NVDA read for me when Callout 1 appeared:

alert
Get back to review checker whenever you see the price tag.  dialog
Close  button
alert
Get back to review checker whenever you see the price tag.  dialog
document
Close  button  
button    Close

I also just noticed that the same issue is present with the Close button for the Shopping sidebar itself. It is not highlighted or read by NVDA on hover. But NVDA does read it on focus, and does automatically advance to it after several seconds if auto reading is enabled.

Comment 7

[Anna Yeddi [:ayeddi]]

Adjusting the a11y severity since this is not a hittesting bug in the Accessibility API. Per James Teh [:Jamie] comment #2 in the bug 1819599:

Do these buttons have visible text or are they icons with a11y labels/tooltips? If they don't have visible text always, NVDA mouse tracking will not read the text, which is a known issue with NVDA mouse tracking.

Comment 8

[Shane Hughes [:aminomancer]]

They don't have visible text, just aria-label and title = "Close"

Comment 9

[Rares Doghi, Desktop QA]

This issue still occurs in our latest Nightly build with the Old as well as the New Callouts v1.1.