aria-actions: handling focus when actions are synthetically triggered

[smhigley]

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.

[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