Closed Bug 1804267 Opened 1 year ago Closed 1 year ago

The dismiss button for the Recently Closed URLs is not read by the Screen Reader when hovered

Categories

(Core :: Disability Access APIs, defect, P2)

Product:
Core
Component:
Disability Access APIs
Version:
Firefox 109
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox109 --- affected

People

(Reporter: gmoldovan, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [foxfooding] [fidefe-2022-mr1-firefox-view])

Found in

  • 109.0a1

Affected versions

  • 109.0a1

Tested platforms

  • Affected platforms: Windows 10, Ubuntu 22.04

Steps to reproduce

  1. Open Firefox and some random web pages in different tabs.
  2. Close some tabs and open Firefox View.
  3. Hover the X button of the Recently Closed section.

Expected result

  • The dismiss button for the Recently Closed URLs is correctly read by the Screen Reader when hovered.

Actual result

  • The dismiss button for the Recently Closed URLs is not read by the Screen Reader when hovered.

Regression range

  • This is not a regression since it's a new feature.

Additional notes

  • On Windows the screen reader reads the URL and the timestamps, but not the dismiss button.
  • On Ubuntu neither the URLs, timestamps or buttons are read when hovered.
  • Everything is correctly read when using keyboard navigation on both Windows and Ubuntu.
Severity: S3 → S2
Priority: -- → P1
Whiteboard: [foxfooding] [fidefe-2022-mr1-firefox-view]
Assignee: nobody → kcochrane
Status: NEW → ASSIGNED

Ray, after some investigation, I think we may need to pull this out of the Fx View sprint, as this needs to be investigated at a larger scale. This is not happening solely within Firefox View. For example, the same is happening with the close button for an active tab in the tabs list at the top of the browser. When hovered, a popup indicates that it's labeled as "Close Tab", but screen readers do not announce it.

Toolbarbuttons do have this working using tooltiptext and label attributes defined in the fluent files, but I think this may be custom logic for those button. (For example, Save to Pocket, Extensions, etc.). It may be something we could replicate here, but it won't address where this is happening elsewhere in the browser.

Flags: needinfo?(rfambro)

Pulling this out of the sprint for now after discussion with the team, but can please you summarize your findings with this as well :ayeddi?

Flags: needinfo?(rfambro) → needinfo?(ayeddi)
Assignee: kcochrane → nobody
Status: ASSIGNED → NEW

Updating the priority since we're pulling it out of the current sprint.

Severity: S2 → S3
Priority: P1 → P2

As Kelly mentioned, this an NVDA bug that we cannot fix on our/Fx end and we are expected to use aria-label vs off-screen text workaround. This is a known mouse tracking bug in NVDA that we can't solve on our end. It occurs because NVDA mouse tracking prefers to use the text interface if present so it can read by line, word, etc. That code doesn't know that aria-label should override for buttons, while for mouse tracking, only visible information is expected by NVDA to be announced. It works for chrome buttons because those don't expose the text interface.

Just in case, Kelly and I run few quick tests with other browsers on Windows and the behavior is the same - no image buttons from the content page are announced by NVDA.

I think we can close the ticket as wontfix

Flags: needinfo?(ayeddi) → needinfo?(rfambro)

Thanks for the confirmation on this Anna! Will close this one out.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(rfambro)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.