Closed Bug 1874154 Opened 6 months ago Closed 5 months ago

Consistent Positioning for "Screenshot Copied!" Indicator


(Firefox :: Screenshots, enhancement, P5)




124 Branch
Accessibility Severity s4
Tracking Status
firefox123 --- wontfix
firefox124 --- verified


(Reporter: sbadau, Assigned: sfoster)


(Blocks 1 open bug)


(Keywords: access)


(2 files)

Found in

  • Nightly 123.0a1

Affected versions

  • Nightly 123.0a1

Tested platforms

  • Affected platforms: macOS 13, Windows 10 and Ubuntu 22.04


  • 'screenshots.browser.component.enabled' is set to true in about:config

Steps to reproduce

  1. Enable Screenshots and Copy a screenshot.
  2. Observe the Screenshot copied! indicator.

Expected result

  • The "Screenshot copied!" indicator should be consistently displayed in the same position, regardless of whether the Screenshots tool has an icon placed on the Toolbar or not. (similar with the "Saved to Bookmarks!" one).

Actual result

  • If the Screenshots button is not placed on the Toolbar, the "Screenshot copied!" indicator is centered on the window. If the Screenshots button is on the Toolbar or Overflow, the indicator appears in the upper right side of the window. Please see the screenshot for more details.

Regression range

  • This is not a regression.

We will see if UX has a better recommendation for the default placement of the confirmation hint.

Flags: needinfo?(sfoster)
Priority: -- → P5
Keywords: access

From the accessibility point of view, while there are no specific WCAG criteria for messages, there are few Success Criteria that would apply here, they are all listed under one guideline - Predictable, because they help users with cognitive disabilities to easier predict and locate content:

  1. Success Criterion 3.2.3 Consistent Navigation - since there are no controls on the toaster, this would not directly apply, but because it does imply kind-of “Okay”ing of the information (a user is aware that the screenshot was, in fact, taken), we’d want to follow it
  2. Success Criterion 3.2.4 Consistent Identification - we want to make sure the user could identify that there is, in fact, a toaster shown. I assume, sadly, the toaster self-dismissing after some short time, this makes it even more crucial for a user to be able to locate it in time.
  3. Success Criterion 3.2.6 Consistent Help - the confirmation message on the toaster would vaguely fall under the fully automated contact mechanism. While the change of the location may be considered to be initiated by a user, I’d argue we still want to ensure the location of the message is consistent.

I think about this use case especially: a user with low vision who has a large screen and even magnifier (physical one or an assistive technology like ZoomText), they can take a screenshot by pressing the toolbar button with a mouse and be able to notice and read notification in time, before it disappears. Then they chose to use a keyboard shortcut, but since there are no controls, the ZoomText software won’t move the viewport of their magnifier to the new location and, recalling that the confirmation was shown on the right hand side near the toolbar before, they are likely to move their viewport to that region (but the toaster won’t be there too and/or would disappear by then). This user would have to repeat the action which is more cumbersome than in would be for a user without a magnifier, etc.

If we place the snackbar to the consistent place in the UI, it would be less taxing on the disabled user.

Accessibility Severity: --- → s4

After some discussion with UX/a11y folks (thanks :ayeddi), there isn't a optimal answer to this question, but maybe a least-worst option is the application menu icon (☰). That puts the confirmation hint in the vicinity of other buttons and notifications, and if they did later add the screenshot button to a toolbar, chances are it would be somewhere close by.

Flags: needinfo?(sfoster)
Blocks: 1878628
Assignee: nobody → sfoster
Pushed by
Anchor the 'Screenshot copied' notification on the hamburger menu button if the screenshot button isn't available. r=niklas
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → 124 Branch

Verified as fixed using the latest Nightly 124.0a1 (Build ID: 20240213221259) on Ubuntu 22.04 x64, macOS 13 and Windows 10 x64.

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