Open Bug 1789945 Opened 2 years ago Updated 1 year ago

[foxfooding] The Firefox View icon (the Nightly logo) "dims" when something else is the focus window on your desktop

Categories

(Firefox :: Firefox View, defect, P3)

Firefox 106
Desktop
Unspecified
defect

Tracking

()

Accessibility Severity s4
Tracking Status
firefox106 --- affected

People

(Reporter: pdehaan, Unassigned)

References

(Blocks 1 open bug)

Details

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

Attachments

(3 files)

Firefox Version: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36
Window Size (inner width and height): 1920x919
GitHub Username: @lime124

Steps to Reproduce

The firefox view icon (the nightly logo) "dims" when something else is the focus window on your desktop. so for example, zoom in the third screenshot is the focus thing and the other two firefox windows are not. the firefox view icon is dimmed. but when the window is in focus the firefox view icon is "not dimmed". it's weird b/c the other tab icons don't do that. all the pinned tabs i have and all the open tabs, none of them dim when it's not in focus.

Expected Behavior

The logo doesn't dim; same as the other favicons.

Actual Behavior

The logo dims unexpectedly.

Attachment


Link to the original attachment

Morgan/Anna -- Is this issue a critical a11y concern?

Flags: needinfo?(mreschenberg)
Flags: needinfo?(ayeddi)

This is happening because of fxview being a button rather than a "real" tab. All the buttons in the screenshot are dimmed.

Blocks: firefox-view
Whiteboard: [foxfooding] → [fidefe-2022-mr1-firefox-view] [foxfooding]

I don’t think this affects accessibility very much, plus as Gijs pointed out it is a default behavior for buttons. Yet, users may not be aware of that distinction or may not think about the View as a non-tab.

Who may be affected are users with low vision and/or color deficiency who are trying to locate a click/touch target - it may be difficult for them to discern the logo and therefore its focus. At the same time the Fx View is expected to be consistently placed at the same position.

Another affected group would be users with magnifiers. I.e. when someone with a ZoomText is reviewing the page and have only 1/4 of the screen seen (with x4 magnification), they may get some notification popped up in another window/app that didn’t move ZoomText view to it, so they are not aware of the other window taking focus - they may get confused why their “tab” with Fx View became “disabled” suddenly (dimmed).

But those are edge cases and I think the severity of this bug is low.

Flags: needinfo?(ayeddi)
Flags: needinfo?(mreschenberg)
Keywords: access
Whiteboard: [fidefe-2022-mr1-firefox-view] [foxfooding] → [fidefe-2022-mr1-firefox-view] [foxfooding][access-s4
Whiteboard: [fidefe-2022-mr1-firefox-view] [foxfooding][access-s4 → [fidefe-2022-mr1-firefox-view] [foxfooding][access-s4]

Yeah I agree with Anna's assessment -- added a11y severity to reflect that.

Severity: -- → S3
Priority: -- → P3
Blocks: 1797520
No longer blocks: firefox-view

We might be changing the icon so we can revisit this and try to improve it if that happens.

Flags: needinfo?(jhall)
Flags: needinfo?(jhall)

Perla -- Any thoughts on this one? I think there are a few opportunities we could consider here. The UR study unveiled that there's a larger discoverability concern for Firefox View. We could test a couple of scenarios here including: 1) different locations for an entrypoint 2) a different logo

We could additionally resurface the conversation around having this function as a button vs a tab as we prep for some experimentation. Thoughts?

Flags: needinfo?(pduenas)
Flags: needinfo?(pduenas)
Accessibility Severity: --- → s4
Whiteboard: [fidefe-2022-mr1-firefox-view] [foxfooding][access-s4] → [fidefe-2022-mr1-firefox-view] [foxfooding]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: