[web] switch from .didGain/LoseAccessibilityFocus to .focus

[yjbanov]

Stop using SemanticsAction.didGain/LoseAccessibilityFocus on the web, start using SemanticsAction.focus. This is because on the web, a11y focus is not observable, only input focus is. Sending SemanticsAction.focus will guarantee that the framework move focus to the respective widget. There currently is no "unfocus" signal, because it seems to be already covered: either another widget gains focus, or an HTML DOM element outside the Flutter view does, both of which have their respective signals already.

More details in the discussion in the issue flutter/flutter#83809.

Fixes flutter/flutter#83809
Fixes flutter/flutter#148285
Fixes flutter/flutter#143337

[mdebbar]

I don't fully understand the difference between SemanticsAction.focus and the others, but the code changes look good to me.

[chunhtai]

don't we also want to send a11yfocus as well?

[yjbanov]

That would be a wrong thing to do. On the web, accessibility focus is not observable through any platform API. If the accessibility focus is indeed detached from the input focus, sending didGainAccessibilityFocus together with focus would make the framework believe a wrong widget has accessibility focus. I think instead, we want the framework to be resilient to the absence of accessibility focus signals (it seems to be the case already for our own widgets; according to flutter/flutter#83809 (comment) it's only used for highlighting, which can be achieved at least on desktop through input focus).

[chunhtai]

If the accessibility focus is indeed detached from the input focus, sending didGainAccessibilityFocus together with focus would make the framework believe a wrong widget has accessibility focus.

but on the web they are not detached, right? or at least we can't tell whether something receives only the a11y focus. but when something receives focus, it must also have received a11y focus?

[yjbanov]

They can be detached on the web too. For example, you can uncheck the following checkbox in macOS VoiceOver utility:

With that checkbox off, you can move the accessibility focus around without moving the input focus. Here's an example of VoiceOver focus being on a text field inside the web page, but when typing your input goes into the address bar instead:

Here's another example, where the a11y focus is on the last name field, but I'm entering the first name field:

You need to take special action to activate the widget under VoiceOver cursor, e.g. Control + Option + Space.

However, there's no listeners we can hook up on the web page to tell where the VoiceOver cursor is headed. So it's not observable to us. That's not a real problem though. The browser already does whatever it needs and determines when input focus should move into the field, and send us a DOM "focus" event. The web engine will simply forward it to the framework as SemanticsAction.focus.

I must say, this detached mode feels confusing to me. I think when both kinds of focus are synchronized, it's easier to use the UI. VoiceOver itself seems to be giving incorrect instructions. For example, when you move focus to a text field, it says "To enter text in this field, type", which is incorrect in this mode as the text field does not yet have focus.

[chunhtai]

I see, so the web just not going to use a11y focus. Now I think of it this is probably correct since native web can't tell which dom has the a11y focus either.

[chunhtai]

LGTM

[mdebbar]

Still LGTM!

[mdebbar]

😣

[kevmoo]

@yjbanov – good to land?

[martin-bautista-nimble]

Hey, any update on this? We're currently hoping this fixes an issue with our automated test framework

[kevmoo]

I think @yjbanov is OOO

[auto-submit]

A reason for requesting a revert of flutter/engine/53134 could
not be found or the reason was not properly formatted. Begin a comment with 'Reason for revert:' to tell the bot why
this issue is being reverted.