I'll be looking at a similar  bug 785923 .

I was inspecting this on my device (iPhone 5s with Chrome 64.0.3269.0 and 63.0.3239.54) and indeed, on most occasions VoiceOver seems to skip the toast after the reauthentication dialogue.

On some occasions, VoiceOver actually read the toast, and on some other ones it started to read it, but then interrupted itself to read the next selected element.

The relevant code is in ios/chrome/browser/ui/settings/password_details_collection_view_controller.mm, the -(void)copyPassword method.

The path which never has problems is the one under "if(_plainTextPasswordShown)", where no focus changes and only the toast is pulled up and then hidden after a while.

The problematic path is the "else if ([_weakReauthenticationModule canAttemptReauth])", where control is given over to iOS's reauth dialogue, and the toast is displayed when that dialogue is completed. At the same time, focus is returned back to Chrome, and VoiceOver reading the toast competes with VoiceOver reading the newly focused element.

I am not sure how to fix that race. lpromero@ would you know or do you have good pointers to people knowledgeable in accessibility on iOS?

You are right, this is a race in VoiceOver, where the snack bar (aka toast, aka HUD) makes an announcement:
http://google3/third_party/objective_c/material_components_ios/components/Snackbar/src/MDCSnackbarManager.m?l=228-251
and the iOS default when the presented screen is dismissed and looses VoiceOver focus in favor of the underlying screen.

Could you postpone showing the snackbar to after the dismiss animation of the iOS passcode screen?

For example:
1-
 https://cs.chromium.org/chromium/src/ios/chrome/browser/ui/settings/password_details_collection_view_controller.mm?l=451
When is this completion called? Probably too soon (i.e. not tied to the screen animation)?

2- In the settings screen, in viewDidAppear, but that's also not ideal, as you'll need to special case the first appearance, and this is not called on iPad when the app is in Regular width…

Thanks, lpromero@, for the helpful thoughts (including clarifying the terminology)!

As for potential events to tie to toast to, what you suggest in 1 is the current state, IIUC, i.e., the toast is shown during the notification of the reauth result from the iOS passcode screen. Number 2 seems like the logical choice, but it's absence on iPad worries me (Stackoverflow [1] seems to confirm that there are no good solutions to that in this case, where we don't control the iOS UI).

Further hacks I am considering include:

 3- Checking if the iOS passcode screen is considered a subview and thus emits a willRemoveSubview. But even if that is the case, this is likely too early (i.e., before the iOS passcode screen actually disappears).

 4- Polling the settings screen for the "focused" property becoming true, with, say a 1 second interval and only display the toast once the screen has focus. This might not be allowed in production code, I'd need to find out.

Yeah, every solution is going to be a hack :(

Two observations:
- Don't forget to take into account people with TouchID and FaceID: in these cases, I think the UI that is presented is not fullscreen. Be sure to check it out, as it will be the case for most users now.
- Can you try to look for instances of this passcode pattern in Apple apps? How does it work within Safari? I'd try to look for such an instance and try to replicate if they solved that problem.

I am a bit pessimistic to find a good workaround, Everything stems from VoiceOver race conditions and the fact that you don't own the presented view controller :(

I'm sadly very unlikely to touch this until I leave the team by the end of the month, so pushing back into the available bugs.