I feel that the issue is with the bubble, not with the accessibility code. If the bubble is modal, any focus events fired outside the bubble should be ignored and not dismiss the bubble. If the bubble is non-modal, why should focus events affect its visibility in any way?
I assume that if a user clicks inside the webpage the translate bubble stays on screen, isn't that so? Why are clicks inside the webpage ignored by the bubble but accessibility focus events not?

The translate bubble is *deliberately* set to dismiss on focus-change. We don't want to perma-nag people about translation, under the assumption that if you interact with the web page, you understand the language.

This might be an inappropriate assumption for the a11y case, I gather?

If you want to experiment with a bubble that doesn't close on focus loss, just set shouldCloseOnResignKey to TRUE for the bubble controller.

Whatever we do, we should *not* add yet another mode that bubbles work in. 

Yes, I believe that for the a11y case, one might need to interact with the page first before figuring out if a translation is necessary. If we block that or change the behavior of how focus works on the webpage while the bubble is visible, it might create confusion or at minimum surprise.
For the general case however, and even though the design of the Translate Bubble is up to you, wouldn't you say that there are cases when the first part of a page is in a familiar language, but when the user scrolls a bit realizes that they need translation?

> wouldn't you say that there are cases when the first part of a page is in a familiar language, but when the user scrolls a bit realizes that they need translation?

I haven't ever encountered one. So my assumption is they're very rare. But even stipulating they exist, the user can always translate later via right-click.

Here's the thing: We have bubbles that auto-dismiss for a reason - remember the stack of infobars you could generate in Chrome at one time? We'd really like to avoid that for bubbles.

It might well be that is problematic for a11y, but then we should discuss a general solution that still satisfies that constraint. Just patching up a particular bubble to stay visible longer merely creates another problem further down the road.

> even though the design of the Translate Bubble is up to you,
That's not really the case :) I'm merely somewhat familiar with how we ended up here, and would like to avoid a repeat of that road. That doesn't mean I get to ride roughshod over a11y/usability concerns - I hear the a11y issue, and I'd like to address it. I just don't think additional focus machinations are the answer.

I know ainslie is looking at bubbles, so maybe he can give some UX guidance...

I don't have the problem with dismissing on an explicit user-initiated focus change.

I think the more significant bug is if the popup is dismissed simply due to the page loading and moving focus within the page. We should handle that separately and not dismiss the popup.

Any concerns with addressing that case first?

No concerns addressing the page loading issue.
For the general case, how about we don't worry about the bubble being dismissed and simply announce the fact that translation is available and how to trigger it. E.g., as soon as the bubble appears:
"Translation available. Press shortcut key to activate."
Or if we don't want to create yet another shortcut key that would be enabled at all times, i.e. regardless of the visibility of the bubble, we could say something like:
"Translation available. Use the context menu to select language."

I want to clarify something: is the bubble dismissing *before* some user event that takes focus? Because that would be a bug. 

I think so. Page is loading, the bubble appears, page fully loads, accessibility sends a notification to put voiceover focus in the Web view, bubble prematurely gets dismissed.
Is that right, Dominic?

[mac triage] Assigning to dmazzoni@ for further action.

Wenwon't ship the bubble UI on Mac so can close as won't fix.