1854133 - The X Close button from the Shopping Sidebar is not read out loud by the NVDA when hovered over using the mouse cursor

Status: NEW

(Firefox :: Shopping, 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 - 1
Have NVDA Enabled.

Steps to reproduce

1. Reach https://www.amazon.com/WOKA-Electric-Standing-Adjustable-Controllers/dp/B09L1KY91X/ref=sr_1_2_sspa?crid=1I1N64FJG4GK7&keywords=standing%2Bdesk&qid=1692776724&sprefix=standing%2Bdes%2Caps%2C218&sr=8-2-spons&sp_csd=d2lkZ2V0TmFtZT1zcF9hdGY&th=1
2. Hover the Mouse cursor on top of the X Close button from the Shopping sidebar.

Expected result

• The X Close button should be read out loud when the user hovers the mouse cursor on top of it.

Actual result

• The X Close button is not read by the NVDA screen reader when hovered.

Regression range
Not Applicable

Comment 1

[Eitan Isaacson [:eeejay]]

Some digging shows the a11y tree looks good. Assuming tabbing to the close tab works fine?
This seems like the (cached) bounds are incorrect. devtools shows the right a11y bounds but accerciser shows the button's x coordinates as lesser than the review checker title which should be to the left of the button.

Not a major product a11y bug, but definitely a core a11y bug.

Comment 2

[Anna Yeddi [:ayeddi]]

(In reply to Eitan Isaacson [:eeejay] from comment #1)

Some digging shows the a11y tree looks good. Assuming tabbing to the close tab works fine?
This seems like the (cached) bounds are incorrect. devtools shows the right a11y bounds but accerciser shows the button's x coordinates as lesser than the review checker title which should be to the left of the button.

Not a major product a11y bug, but definitely a core a11y bug.

After digging a bit around for the bug 1854153, it looks like we would either need to fix the caching of the bounds or we could use an icon as <img> element within a button - 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>

Comment 3

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

This seems like the (cached) bounds are incorrect

Looks like this is an a11y bug, perhaps? Kicking over to core::a11y

Comment 4

[Anna Yeddi [:ayeddi]]

While a button does not have any visible text always, NVDA will not read the label, which is a known issue with NVDA mouse tracking.

Since the button does have an accessible name provided (which can be checked in the Devtools Accessibility inspector), the lack of on-hover announcement, in this case, is the NVDA bug.

What we could do to make the user experience better is either:

1. to add an on-screen text next to color option circles, so there is an on-screen text (that is included in the option markup) - this should be announced by the NVDA.
2. to add an invisible <span> in the button as Calixte offered in the bug 1886964#c1 and in the attached patch. This would also work as an accessible name source for the button.

I'll move it back to the Shopping component and change the a11y triage as access-s4 since this is not a delightful pattern in any case, but yet the issue is not as severe and is largely dependent on the assistive technology software.

Comment 5

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

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

For more information, please visit BugBot documentation.