1884625 - Voice Over does not read the 'Screenshot copied' notification when copying via Save dialogs

Status: ASSIGNED

(Firefox :: Screenshots, defect, P2)

Description

[Simona Badau, Desktop QA, PTO 22-30June]

Found in

• Nightly 125.0a1

Affected versions

• Nightly 125.0a1

Tested platforms

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

Preconditions

• Enable Voice Over.

Steps to reproduce

1. While Voice over is running, enable Screenshots.
2. Using the VO commands, reach the Save visible dialog and open it.
3. Using the VO commands, click on the Copy button.

Expected result

• The user should be notified that the Screenshot was copied.

Actual result

• The 'Screenshot copied' notification is displayed after Copy, but the user is not notified by the Screenreader.

Regression range

• This is not a regression, reproducible only with the component version of Screenshot.

Additional notes

• Same behaviour is encountered when copying via "Save full page" dialog.
• 'Screenshot copied' message is read if doing a copy via mouse selection.

Comment 1

[Nathan LaPré]

Looks like an access-s2 because the information isn't available to blind users, and it doesn't seem like there's a workaround. FWIW, this does work on NVDA on Windows, though NVDA reads the "screenshot copied" message 3-5 times.

Comment 2

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

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:sfoster, could you consider increasing the severity?

For more information, please visit BugBot documentation.

Comment 3

[Sam Foster [:sfoster] (he/him)]

We use the ConfirmationHint in browser.js for this notification. Can you confirm if the same problem exists when you bookmark a site? (You'll need a new profile or to reset the browser.bookmarks.editDialog.confirmationHintShowCount pref to get the confirmation.)

Comment 4

[Simona Badau, Desktop QA, PTO 22-30June]

Initially, the "Saved to bookmarks" notification is read by the VO 3 times, and as expected this is reflected by the setting browser.bookmarks.editDialog.confirmationHintShowCount = 3.
However, after these 3 instances, the "Saved to bookmarks" notification is neither read nor displayed anymore.
Additionally, it is noted that the browser.bookmarks.editDialog.confirmationHintShowCount setting does not increase beyond 3.

Comment 5

[Sam Foster [:sfoster] (he/him)]

Do you think this bug should block getting the new screenshots UI into Release on this bug :ayeddi?

Comment 6

[Morgan Reschenberg [:morgan]]

How do I enable screenshots to test this?

Comment 7

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

:Simona, could you please share more details on the Step 1 of STR, so we're testing the same notification?

Comment 8

[Simona Badau, Desktop QA, PTO 22-30June]

(In reply to Morgan Reschenberg [:morgan] from comment #6)

How do I enable screenshots to test this?

I usually enable Screenshots like this:

1. By clicking the Screenshots button that I place on the Address bar (click on Open Application menu -> More Tools -> Customize Toolbar and drag the Screenshots button over the Address bar).
2. Using the keyboard shortcut: CMD + Shift + S.

After Enabling the Screenshots tool using any of the above method I proceed with reaching to the Save dialog option and clicking it using the VO instructions. Using the the Voice Over instructions I then reach and click ont the Copy button.

Comment 9

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

Thank you for the instructions, Simona!

(In reply to Sam Foster [:sfoster] (he/him) from comment #5)

Do you think this bug should block getting the new screenshots UI into Release on this bug :ayeddi?

To answer your question, Sam: yes, since this notification is provided for sighted users and we want to make sure important information such as a status (that would also affect your next steps in the flow) is communicated equally to all users.

Per the internal discussions with my team who are more versed in the VO specific hacks, it seems that A11yUtils.announce could resolve the issue as it is done for hints within the URL Bar (example with an explanation included), ref.

Comment 10

[Morgan Reschenberg [:morgan]]

I've been debugging this since late last week and haven't made any progress on getting VO to announce this. I'm gonna try some more today.

Are we firing the notification from a live region that gets dynamically added and removed?
I wonder if VO is refusing to send the notification because the live region is remove before VO processes the change.
In general, VO is pretty picky about live region stuff :( a11yUtils.announce isn't foolproof either, though I've done a lot of work on it.

Comment 11

[Sam Foster [:sfoster] (he/him)]

(In reply to Morgan Reschenberg [:morgan] from comment #10)

Are we firing the notification from a live region that gets dynamically added and removed?

The ConfirmationHint lazily creates axul:panel using the markup in main-popupset.inc.xhtml. The hint text is then inserted into the element using document.l10n.setAttributes.

We do use this technique elsewhere - a lot of our UI sits inert in templates until its first used. But I can see how this might confuse the VO. Particularly as this one is kind of a toast - a panel which animates out after a few seconds.

Thanks for the confirmation - yeah we can block on this.

I'd guess we want to call A11yUtils.announce("") in the popupshown handler. Are you actively working on this :morgan, or should I put together a patch?

Comment 12

[Morgan Reschenberg [:morgan]]

(In reply to Sam Foster [:sfoster] (he/him) from comment #11)

(In reply to Morgan Reschenberg [:morgan] from comment #10)

Are we firing the notification from a live region that gets dynamically added and removed?

The ConfirmationHint lazily creates axul:panel using the markup in main-popupset.inc.xhtml. The hint text is then inserted into the element using document.l10n.setAttributes.

We do use this technique elsewhere - a lot of our UI sits inert in templates until its first used. But I can see how this might confuse the VO. Particularly as this one is kind of a toast - a panel which animates out after a few seconds.

Thanks for the confirmation - yeah we can block on this.

I'd guess we want to call A11yUtils.announce("") in the popupshown handler. Are you actively working on this :morgan, or should I put together a patch?

I'm not actively working on the screenshots code, just debugging in the accessibility module. If you could post a patch that'd be great -- I anticipate it won't work smoothly with VO right now, so if you test it and that's the case please NI me and I'll work on debugging your patch specifically :) but it's much easier to work with something that uses a11yUtils.Announce than anything else.

Comment 13

[Sam Foster [:sfoster] (he/him)]

Attachment: Bug 1884625 - Call A11yUtils.announce() when a confirmation hint is shown. r?morgan

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8036a50c0751
Call A11yUtils.announce() when a confirmation hint is shown. r=morgan

Comment 15

[Natalia Csoregi [:nataliaCs]]

Backed out with Bug 1888310 for causing failures on browser_app.js

• backout: https://hg.mozilla.org/integration/autoland/rev/7ed2595827888ad532d19d2cf3ae701994f83d6c

Comment 16

[Sam Foster [:sfoster] (he/him)]

[Tracking Requested - why for this release]: We're planning to fix and ship the pref flip in bug 1870127 in 127, which would expose this bug (its currently nightly only.)

Comment 17

[Sam Foster [:sfoster] (he/him)]

Talked to :morgan and we don't need to block on this as it is MacOS only - while they reconsider the approach to Bug 1888310.

Comment 18

[Donal Meehan [:dmeehan]]

Clearing tracking request in Comment 16 based on Comment 17