aria-actions: handling focus when actions are synthetically triggered

[smhigley]

Amended Issue Description: Per discussion in January 15, 2026 ARIA WG telecon, the original dewscription of this issue by @smhigley has been amended by @mcking65 to include content on focus management use cases and the questions they raise.

The problem:

When actions are triggered from the referencing element e.g. through the actions rotor or an actions-specific UI, the desired UX would be for focus to stay on the referencing element.

Right now, it moves to the action as a natural result of triggering a click event.

Possible solutions:

1. Do not call focus on the action when synthetically triggering it. Pros: best user experience. Cons: AT detection vector?
2. Call focus back on the referencing element immediately after the click. Pros: less of a detection vector. Cons: depending on the timing, this could trigger SR behavior like mode switching, starting to read the change, etc.
3. ??

I've chatted with Jamie, Brett, and Chrome folks, and there are no technical issues with implementing any of these solutions. The question is mostly around whether implementing specific focus behavior after synthetically triggering it is a privacy concern.

Focus Management Use Cases

To analyze the efficacy of potential solutions, it is helpful to walk them through the focus management requirements presented by specific aria-actions use cases. Following are several use cases based on the
APG Experimental Example of Scrollable Listbox with Actions on Options.

Note: that as of Jan 18, 2026, this example is still a PR. In December, the task force discussed redesigning the content to make it more realistic and approachable. The functionality and structure of the example will largely remain as is, so the relevance of the use cases will be preserved. However, the details of the use cases may need to be revised as the example evolves.

Overview of scenario and use cases

Let's consider a specific scenario where a user wants to:

1. Use the "Move Up" action to move the "Californium" option up two positions in the list from 7 to 5.
2. Use the "Favorite" action to mark "Californium" as a favorite.

Below, the steps for executing this scenario and their expectations are described for 3 use cases: a screen reader user, a keyboard user, and a mouse+keyboard user.

Use Case 1: Screen Reader User

• This use case is in VoiceOver for iOS terms since it is one platform where many people understand the commands and expectations.
• It assumes that:
  • The listbox element has DOM focus.
  • The value of aria-activedescendant refers to "Californium" before step 1 is performed.
• Note: This use case is hypothetical; it cannot be tested with the APG example because Safari does not yet implement support for aria-actions.

Step	Commands	Expectationss
1 - Select the "Move up" Action	swipe down OR VO-CMD-DownArrow	VO announces "Move Up". DOM focus remains on the listbox and aria-activedescendant still refers to Californium.
2 - Activate the "Move up" Action	Double Tap OR VO-Space	VO announces the live region notification "Moved to position 6". DOM focus remains on the listbox and aria-activedescendant still refers to Californium.
3 - Activate the "Move up" Action	Double Tap OR VO-Space	VO announces the live region notification "Moved to position 5". DOM focus remains on the listbox and aria-activedescendant still refers to Californium.
4 - Select the "Favorite" Action	swipe down twice OR VO-CMD-DownArrow twice	VO announces "Move Down" then "Favorite". DOM focus remains on the listbox and aria-activedescendant still refers to Californium.
5 - Activate the "Favorite" Action	Double Tap OR VO-Space	VO announces the live region notification "Favorited Californium". DOM focus remains on the listbox and aria-activedescendant still refers to Californium.

Use Case 2: Keyboard User

The following steps assume that:

• The listbox element has DOM focus.
• The value of aria-activedescendant refers to "Californium" before step 1 is performed.

Note: Changes to the value of aria-activedescendant remain essential in this use case because the keyboard user may be a screen reader user who is not using screen reader commands to activate the actions.

Step	Commands	Expectationss
1 - Select the "Move up" Action	RightArrow	DOM focus remains on the listbox, and the element referenced by aria-activedescendant changes from "Californium" to the "Move up" button.
2 - Activate the "Move up" Action	Enter OR Space	Californium moves up, DOM focus remains on the listbox, and the element referenced by aria-activedescendant continues to be the "Move up" button for the "Californium" option.
3 - Activate the "Move up" Action	Enter OR Space	Californium moves up, DOM focus remains on the listbox, and the element referenced by aria-activedescendant continues to be the "Move up" button for the "Californium" option.
4 - Select the "Favorite" Action	RightArrow twice	DOM focus remains on the listbox, and the element referenced by aria-activedescendant changes from "Move Up" to the the "Favorite" button.
5 - Activate the "Favorite" Action	Enter OR Space	The "Californium" option is marked as a favorite, DOM focus remains on the listbox, and the element referenced by aria-activedescendant continues to be the "Favorite" button for the "Californium" option.

Mouse+Keyboard user

The following steps assume that:

• "Californium" is scrolled into view when step 1 is performed.
• The listbox element may NOT have DOM focus.

Note: This use case differs from use case 2 only in steps 1 and 2.

Step	Commands	Expectationss
1 - Select the "Move up" Action	Hover over "Californium" and then move the pointer over the "Move up" button	Focus (document.activElement) remains wherever it was; it could be anywhere on the page.
2 - Activate the "Move up" Action	Click	DOM focus is set on the listbox, aria-activedescendant is set on the listbox to refer to the "Move up" button for the "Californium" option, and the "Californium"option moves up.
3 - Activate the "Move up" Action	Enter OR Space	Californium moves up, DOM focus remains on the listbox, and the element referenced by aria-activedescendant continues to be the "Move up" button for the "Californium" option.
4 - Select the "Favorite" Action	RightArrow twice	DOM focus remains on the listbox, and the element referenced by aria-activedescendant changes from "Move Up" to the the "Favorite" button.
5 - Activate the "Favorite" Action	Enter OR Space	The "Californium" option is marked as a favorite, DOM focus remains on the listbox, and the element referenced by aria-activedescendant continues to be the "Favorite" button for the "Californium" option.

Questions

1. Should we be aiming to enable AT and browsers to support all three of the above use cases without putting undue burden on authors?
2. If not, how would that impact the utility of aria-actions?
3. If yes, what are the browser requirements?

[mcking65]

@smhigley wrote:

Possible solutions:

1. Do not call focus on the action when synthetically triggering it. Pros: best user experience. Cons: AT detection vector?
2. Call focus back on the referencing element immediately after the click. Pros: less of a detection vector. Cons: depending on the timing, this could trigger SR behavior like mode switching, starting to read the change, etc.
3. ??

I believe there are more cons associated with option 2:

1. If the action causes a focus change, e.g., opens a menu, then the resulting focus would be indeterminant, i.e., a matter of timing.
2. If the action opens a menu or dialog, escaping out of the menu or dialog would not return focus to the referencing element.
3. Focus change events could interfere with notifications generated by an action. Example: In a shopping cart, the referencing element is an item, the action is increase quantity, and the result of increasing is notification of the new quantity. The user should be able to execute the action multiple times without focus leaving the item and hear the new quantity after each execution of the action.
4. If the action causes destruction of the referencing element, then the browser's attempt to set focus would interfere with the author's ability to manage focus.

[cookiecrook]

4. If the action causes destruction of the referencing element, then the browser's attempt to set focus would interfere with the author's ability to manage focus.

Is it sufficient to add an author requirement to handle focus changes when the action is triggered... whether it's triggered by a mainstream click event or synthesized AT-triggered click event?

[css-meeting-bot]

The ARIA Working Group just discussed aria-actions: handling focus when actions are synthetically triggered.

The full IRC log of that discussion

<Daniel> sarah: The behavior we want is on the referencing element you wnat to be able to choose the secondary action, activate, and stay on the primary action
<Daniel> ... But activation triggers focus to the secondary action, which is not desired user expectationisbehavior
<Daniel> ... From the browser's perspective it's easy to just not call focus, but that may have privacy/security implications
<Matt_King> q+
<jamesn> q+
<Daniel> ... We could move focus back to primary just after it's moved to secondary, but that may create oddities in AT behavior
<spectranaut_> ack Matt_King
<Daniel> Matt_King: I commented on this issue with what I wanted to say
<front-endian-jane> q+ to comment about authoring concerns with option 2
<Daniel> ... If the action itself causes (or should cause) a focus change, the result may not be that you want focus to immediately go back
<jamesn> q-
<Daniel> ... However, if it opens a menu/dialog or similar that's when you do want focus back
<Daniel> ... What if the primary element is destroyed
<Daniel> ... For example, actions to increase the product quantity, which are expected to be performed repeatedly, you'd like to here the updated amount but still keep focus on the trigger
<spectranaut_> ack front-endian-jane
<Zakim> front-endian-jane, you wanted to comment about authoring concerns with option 2
<jcraig> q+
<jamesn> q+
<spectranaut_> ack jcraig
<Daniel> Jane: Option 2 may cause author errors. Agree.
<Daniel> JamesC: I may change my mind later when I fully review the thread.
<Daniel> ... Some clarifying questions
<Daniel> ... In the gmail-like scenario -- I think gmail is doing a smart inteerception of the click event, it might be a known issue
<Daniel> ... Second -- "less of a detection vector". How could this be a detection vector?
<Daniel> sarah: Because keyboard could also trigger focus change
<Daniel> JamesC: I'll think some more about that one
<sarah> q+
<Daniel> JamesC: From Matt_King's list
<Daniel> ... We could add some advice to the implementation that the center point of the similar event doesn't have these capabilities
<Daniel> Matt_King: Are yo saying that if you use option 1 you can obscure it with the location to be randomized?
<Daniel> JamesC: Time in particular, timing should'nt be predictable. Triggering a click and triggering a focus after some seconds may be even more of a detection vector
<Daniel> s/vector/vector because it's multiple events that are synthesized/
<spectranaut_> ack jamesn
<Daniel> JamesN: A well-written application where the button itself can take care of moving the focus back where it was
<Daniel> ... This is not a requirement. I don't think this should block us
<Daniel> ... #1 has privacy issues, #2 is subjected to author errors
<spectranaut_> q?
<Daniel> Matt_King: All the examples we've come up with, aria-actions doesn't end up adding any value at all if the focus change happens. There's literally no point in having aria-actions
<spectranaut_> ack sarah
<Daniel> sarah: I wouldn't go that far -- having aria-aactions still tels you that there are actions
<Daniel> ... If you are using a screen reader virtual cursor your focus is moving randomly without pretty much any interaction, which in itself can be used for tracking
<Daniel> ... If folks are oK with this then there might not be a problem
<Daniel> JamesC: I wouldn't implement something differently than mainstream would do
<Daniel> ... If something moves focus "mainstream", it should move it too
<Daniel> ... We should add an author requirement to manage the "focus back" afterwards
<Daniel> Matt_King: There's a challenge. IF you put an author requirements that means author can't support a combination of mouse/keyboar users
<Daniel> ... If you say that author shouldn't allow focus to be moved via click that creates another accessibility problems
<Daniel> JamesC: Author should manage that, didn't say shouldnt move
<sarah> q+
<Daniel> Jane: If someone triggers and action in a menu, if it's a mouse user that clicked on it I want to close the menu
<Daniel> ... How could I distinguish these?
<Daniel> JamesC: I don't think you should keep focus in the menu item regardless
<Daniel> Matt_King: We'd appreciated help from this group to solve our current proposed examples. One is a set of tabs with actions, another is a list box with possible actions for each element on the list
<jcraig> q+
<Daniel> ... In the list box, if the mouse click hovers and clikcs the button, we do want focus to be on that button, but if the screen reader is on the list item and clikcs the button via the action item, we don't want focus to go there
<jcraig> q+ to acknowledge we're using two different definitions of "focus management"
<spectranaut_> ack sarah
<Daniel> sarah: This is hard to resolve from an author's perspective
<Daniel> ... Even if you try you'd still have the focus bouncing. If we can do that that'd e the best approach. I don't think that's achievable by authors at this point
<spectranaut_> q+ bryan
<spectranaut_> ack jcraig
<Zakim> jcraig, you wanted to acknowledge we're using two different definitions of "focus management"
<Daniel> JamesC: Different definitions of managing focus. Matt was talking about the ARIA definitions, I was talking more generically about author controlling focus
<Daniel> ... For the tab container, if you trigger this you'd change to tab container and move focus
<Siri> q+
<Daniel> ... In the menu, it'd trigger a click event in one of these aactionable elements and then whatever happens results in another UI event which will need focus handling anyways
<Daniel> sarah: An action on every column header to sort. You want to be able to trigger the action without the focus moving to the inside button every time
<Daniel> Matt_King: The APG examples are not at all as you're describing
<Daniel> JamesC: Please link them to this issue
<Daniel> Matt_King: I'll do
<spectranaut_> ack bryan
<Daniel> Bryan: Is there an event?
<Daniel> JamesC: It's possible, but we talked about intentional events triggering AT events and it didn't really work
<Daniel> Siri: Are we talking about actions that appear on hover or on focus? Or about menus and sub menus?
<Daniel> ... Focus management would be done differently for each
<jcraig> q+ to answer Siri
<jcraig> ack Siri
<Daniel> ... How are we trying to differentiate this?
<sarah> q+
<spectranaut_> ack jcraig
<Zakim> jcraig, you wanted to answer Siri
<spectranaut_> zakim, close the queue
<Zakim> ok, spectranaut_, the speaker queue is closed
<Daniel> JamesC: Actions is a concept from VoiceOver, we are trying to come up with a way to implement this on the web. It's primitive. It only triggers the action based on what the app originally does
<Daniel> ... Some of the proposals here may allow for AT detection
<Daniel> sarah: Does VO move focus?
<Daniel> Matt_King: VO triggers the action and sends it to the app through the api, then the app does whatever they decide
<Daniel> sarah: Maybe click but not focus on the action is the way to go
<Daniel> ... user events may not be a problem for AT detection cause they are everywhere
<giacomo-petri> +1 to activating but not moving and allow authors to manage it if they think differently
<Daniel> James: the iOS implementation doesn't trigger the "tap" event
<Daniel> ... It should have the exact same behavior as a mouse click would have on the web
<Daniel> sarah: Theoretically yes
<Daniel> Jane: The user experience wouldn't be as good if author doesn't have the ability to maintain focus. But that'd be differentiating the screen reader experience
<Daniel> JamesC: As a web author you can intercept that click
<Daniel> Jane: But I cannot only do it for screen reader user and not for mouse user
<Daniel> JamesC: Why would a mouse user wnat that?
<giacomo-petri> q+
<Daniel> Matt_King: I talked earlier about these two different expectations
<giacomo-petri> q-
<Daniel> sarah: You also don't want the focus back
<Daniel> JamesC: VO has the ability to follow mouse events based on VO settins
<Daniel> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-aria-minutes.html Daniel
<Daniel> JamesN: I am assuming the order of events is going to be the same, we could use the same for sccreen reader users
<Daniel> sarah: You don't want to prevent focus unless the event is triggered by the action
<Daniel> JamesN: Focus could be there already.
<Daniel> Janes: You click there with the physical mouse and then you go back to the keyboard, there might be a different behavior
<Daniel> JamesN: You just want focus to be there
<Daniel> sarah: To prevent focus going there you should call focus somewhere else
<Daniel> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-aria-minutes.html Daniel
<Daniel> zakim, end meeting

[front-endian]

@smhigley and @cookiecrook, while looking through the examples that Matt King brought up I was thinking through the AT detection issue:

Is option 1 any more of an AT detection vector than option 2 when it comes to realistic "attacks"? If someone wanted to use ARIA actions to detect AT usage what is stopping a "malicious" author from creating visibly hidden buttons which can't be tabbed onto during normal keyboard usage? The only convenient way to access them would be through ARIA actions, so won't a detection vector exist no matter how focus is moved?

I'm not bringing this up as an issue with ARIA actions (one can do similar things already on websites if they really want to detect AT usage), but this makes me wonder whether option 1 is actually opening up a dangerous new detection vector. (Apologies if I'm missing something or misunderstanding!)

[cookiecrook]

examples that Matt King brought up

Will someone link those here?

what is stopping a "malicious" author from creating visibly hidden buttons

Nothing.

• Several core architectural features of the Web Platform may allow heuristic detectability of assistive technology w3ctag/design-principles#293

[daniel-montalvo]

@cookiecrook

• List box example
• Couldn't find the Accordion example. Will come back and update this if I find it later.

[mcking65]

The content of this comment has been revised and moved into the issue description per discussion in the Jan 15, 2026 ARIA WG telecon.

[css-meeting-bot]

The ARIA Working Group just discussed aria-actions: handling focus when actions are synthetically triggered.

The full IRC log of that discussion

<Zakim> agendum 3 -- [aria-actions: handling focus when actions are synthetically triggered](https://github.com//issues/2691) -- taken up [from agendabot]
<jamesn> https://github.com//issues/2691#issuecomment-3756179252
<front-endian-jane> Matt_King: I just added a comment to it that should help move the discussion forward (see link above)
<front-endian-jane> Matt_King: The point of the comment is at the end in the three questions it is asking. I give an example of one of the potential usages being developed for the APG (though the task force is discussing making changes to that change, we may branch the PR so the link to this example is stable). I present the use case three scenarios of different ways a user would interact with it.
<front-endian-jane> Matt_King: JAWs currently doesn't do anything because of the blockers in this issue. The Expectations column in each scenario gives what the expected outcome is in the UI, not what the browser is expected to do.
<jamesn> q?
<front-endian-jane> Matt_King: I think that we need to support these scenarios, and I'm not sure that the suggested solution that Sarah presented would solve the screenreader case completely.
<front-endian-jane> jcraig: Question: these are speculative expectations?
<front-endian-jane> Matt_King: Only for the screen reader. For all the others it is how the example currently behaves.
<front-endian-jane> jcraig: Screenreader here is a stand in for many other ATs?
<front-endian-jane> Matt_King: yes
<front-endian-jane> jcraig: When focus is mentioned here it is unclear if it is referring to AT focus or keyboard focus?
<front-endian-jane> Matt_King: I tried to be careful about that and may need to add some words to make it 100% clear when each focus is referred to. I can correct that.
<np-at> In this example, the browser focus remains on the listbox, aria-activedescendant is what is shifting, correct?
<jamesn> q?
<front-endian-jane> jcraig: We may need to move the example so people without admin privileges can play with it.
<front-endian-jane> jcraig: If the author receives the click and then calls focus on something else, then we do want to follow that particular notification?
<front-endian-jane> Matt_King: I wanted to add another scenario for completeness where it is a destructive action and focus has to move. That may add some edge cases that would be useful to document.
<front-endian-jane> jcraig: It isn't just destructive actions where the author moving focus can change things?
<front-endian-jane> Matt_King: True
<front-endian-jane> jcraig: Do we want to move the table into the description at the top so it's easier for people to see when they first come to it.
<front-endian-jane> Matt_King: That would be cleaner so it isn't lost as discussion continues in future comments.
<front-endian-jane> q+
<np-at> q+
<jamesn> Q- front-endian-jane
<jamesn> Ack np-at
<jcraig> q+ to reply to np-at
<front-endian-jane> np-at: For the destructive actions, is that up to the author to indicate? There are occasions where depending on the author' intent it may make sense to revert focus back to something else. It seems like it should be left up to the author's discretion for that?
<front-endian-jane> Matt_King: My understanding is that it is completely up to the author to manage focus.
<jamesn> Ack jcraig
<Zakim> jcraig, you wanted to reply to np-at
<front-endian-jane> jcraig: My suggestion included that we don't ever prevent authors from having control over where focus goes.
<jamesn> q?
<front-endian-jane> jcraig: That is a goal for what we want to be achievable, but if the action does something behind the scenes, and the triggering element is still in the view, focus shouldn't move from where the user already is even though the button being clicked via the action is elsewhere.
<front-endian-jane> Matt_King: We can test out this scenario with the different options and add other test scenarios if needed. My suggestion is that for each option we consider, write down for each scenario what specifically isn't possible, thus why we would rule it out.
<front-endian-jane> Matt_King: I will move the table into the first comment, and may add a destructive scenario if needed, but maybe we should wait since it may add too much complexity.
<np-at> the destructive behavior should fall under the existing focus management guidelines
<front-endian-jane> jcraig: The reason why I disagree with that is that Matt's examples write test expectations for when focus shouldn't move as part of this. So in the cases where it absolutely should move, we should document that so we are sure that any implementations know they are expected to continue to follow other standard focus handling procedures.
<jamesn> agenda?
<front-endian-jane> jcraig: Keyboard focus shouldn't do anything new, but we are discussion management of AT focus in the scenarios Matt presented as that may have some different behaviors than what we currently do.
<front-endian-jane> jcraig: example, in gmail if you hover over the row you get buttons to reply, forward, delete, etc. If the user hits an action on the star button, standard keyboard focus moves onto the star but AT focus remains on the row.
<front-endian-jane> zakim, next item

[cookiecrook]

Discussed in the ARIA call today. @mcking65 is going to move his tables of expectations into an update/addition to @smhigley's original problem description, so we can all edit it ongoing as the expectations change. I'll provide further updates there.

[cookiecrook]

One addition I plan to add is test expectations for an author-generated kb focus change (e.g. .focus()) as part of the action handler... We want to make sure any kb-focus-changed notifications that are made as an artifact of the click event are ignored by AT (if the author does not use e.preventDefault(); etc), but any follow up kb-focus-changed notifications triggered purposefully by the web author (e.g. newView.focus()) are still registered by the AT.

[mcking65]

@cookiecrook

I have moved the scenario and use cases into the issue description. I revised the content to be explicit about DOM focus and aria-activedescendant. I also clarified assumptions for each use case, and numbered them to make them easier to discuss.