Add browser requirements that support synthetic activation by AT

[mcking65]

Closes #2691

Note: Base branch is not main; it is the compare branch for #1805 (secondary-actions).

• Require browsers to use author-provided names
• Add browser requirement about sequencing actions
• Add browser requirement to prevent default focus-transfer behavior when an action is synthetically activated by an AT

[spectranaut]

Discussed in today's ARIA meeting: https://www.w3.org/2026/06/04-aria-minutes.html#4500

[jcsteh]

The big concern here is AT detection. On one hand, yes, there are many ways to detect AT if you are determined to do it. On the other hand, the "Don’t reveal that assistive technologies are being used" web platform design principle makes it incumbent on us to avoid "obvious" exposure. And yet we have a pretty significant user experience issue here, so we're somewhat caught between a rock and a hard place.

I guess the question is whether bouncing focus back to the originating element is ultimately any better and whether it causes undesirable AT behaviour that is difficult or impossible for ATs to work around. Alternatively, perhaps browsers could move the focus there and back, but avoid firing accessibility focus events while that's happening. I need to think on how that could be implemented so I can try it out.

[mcking65]

If the browser were to automatically move focus back to the referencing element, wouldn't that also create an AT detection path?

How would the browser move focus automatically back to the referencing element without interfering with focus movement triggered by the script that is executed when the referenced element is activated? Would it trigger that focus movement before it executes the script triggered by the referenced element? That seems like it would be very complex to do in a reliable way.

[jcsteh]

If the browser were to automatically move focus back to the referencing element, wouldn't that also create an AT detection path?

Perhaps. Of course, focus can be moved via means other than mouse and AT (e.g. keyboard), but it's true that such means would fire their own events. @smhigley rightly pointed out to me separately that we already have this potential detection path where AT causes focus to move without other input events that would normally trigger that. I still don't think an existing detection path is necessarily an excuse to introduce a new one, but I do agree that these are closely related.

How would the browser move focus automatically back to the referencing element without interfering with focus movement triggered by the script that is executed when the referenced element is activated?

When you click a control, the browser sets focus itself; that's not controlled by script unless script prevents the default event behaviour. If you're talking about the case where a control sets focus itself based on a click event, I don't think we can really handle that, and that would cause problems even if the browser didn't move focus at all for aria-actions. In that case, focus would just end up wherever the script told it to go.

If we were to go down the path of bouncing focus back to the origin, I think it would go something like this:

1. An AT user triggers something via aria-actions.
2. If the element hosting the actions is focused, the browser stores the focus origin, as well as the action target.
3. The browser sends a click event to the action target.
4. The click event may cause focus to move to the action target.
5. If focus does move to the action target, the browser suppresses this accessibility event.
6. The browser waits at least 1 tick.
7. The browser checks the current focus. If it is equal to the action target stored in (2), it restores focus to the origin stored in (2).
8. The browser suppresses the accessibility event for (7).

There are some potential problems with suppressing focus events as described in (5) and (8). For example, focusing the action target might fire more events than just a focus event (e.g. caret event) and we're not going to be able to suppress all of those. This is also completely untested, so there might be things I haven't accounted for.

[mcking65]

My concern was making sure the "bounce focus back" response that could happen in step 7 can't override a desirable focus change that would be executed by the author's script that responds to the click event in step 3.

In step 7, you specified a check to make sure that such a focus change hasn't already happened. If the way that the browser engine runs guarantees that the author script cannot execute a focus change between the time the browser checks the focus location in step 7 and the time the browser initiates a bounce focus back response to that check as part of step 7, then the bounce back response would not be able to interfere with the author's intent.