Closed Bug 1402055 Opened 7 years ago Closed 5 years ago

Turn off the Accessibility indicator when Narrate is disabled

Categories

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

Product:
Core
Component:
Disability Access APIs
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Tracking Flags:
Tracking Status
firefox56 --- unaffected
firefox57 - fix-optional
firefox58 --- affected

People

(Reporter: jaws, Unassigned)

References

Details

Attachments

(1 file)

accessibility.PNG
(deleted), image/png
Details
STR: On Windows 10, start up Firefox Using the Windows 10 Settings app, enable the "Narrate" feature Give focus to the Firefox window Notice that the Accessibility indicator appears Turn off the "Narrate" feature from the Windows 10 Settings app Look at the Firefox window Expected results: The Accessibility indicator should hide Actual results: The Accessibility indicator remains visible until restart [Tracking Requested - why for this release]: the Accessibility indicator is a new feature for 57 and the above steps-to-reproduce show a very likely use-case that users may follow when they see the indicator
Alex or Yura, would either of you be able to work on this?
Flags: needinfo?(yzenevich)
Flags: needinfo?(surkov.alexander)
We should decide on how we want to shutdown the accessibility engine, because screen readers don't say anything like goodbye before shutting down. Offhand, we could try to start a timer for 1sec and see if are not poked by WM_GETOBJECT messages (on Windows), and if so, then shutdown the a11y engine. Would it be a safe assumption? ni'ing Jamie and Aaron for their insight.
Flags: needinfo?(surkov.alexander)
Yeah looking for a WM_GETOBJECT subsequent to something like focus events should be a workable hack. It would be risky for 57 IMO, but I think this is a good thing to work on soon.
Theoretically it is possible that there could be other activity over time without any WM_GETOBJECTs, but from a practical standpoint it is doubtful that any ATs would go long without doing so.
While this is a bug, I am not sure I'd consider this a must fix for 57. Pushing the tracking nom to 58. If a fix is ready soon (in the next week or two) and is low risk, please nominate for uplift to beta57.
tracking-firefox57: ? → -
tracking-firefox58: --- → ?
Alex would you mind setting a priority here? Is this going to be worked on for 58?
Flags: needinfo?(surkov.alexander)
(In reply to Julien Cristau [:jcristau] from comment #7) > Alex would you mind setting a priority here? Is this going to be worked on > for 58? Let's go with p2 (aka needs a fix but not urgent). It's definitely something good to have but probably has restricted impact on real users, because if a user uses a screen reader, then there's no reason to close it. We might have accessibility clients that needs accessibility on temporary basis, but I am not aware of it. Having said that, I would avoid moving the bug into backlog, because even if we don't have that data, it doesn't mean such accessibility clients don't exist.
Flags: needinfo?(surkov.alexander)
Priority: -- → P2
Flags: needinfo?(jkt)
Closing old needinfo request. It would still be nice to get this in for 58 if possible.
Flags: needinfo?(yzenevich)

The accessibility indicator is no longer ever enabled in normal usage. The underlying issue stands - we don't shut down the a11y engine after a client stops using it - but fixing that isn't likely to have much impact in the real world. Closing.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Keywords: regression
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: