Skip to content

Add browser requirements that support synthetic activation by AT #2806

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mcking65 wants to merge 1 commit into
base: secondary-actions
Choose a base branch
from
Open

Add browser requirements that support synthetic activation by AT #2806

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10270,7 +10270,9 @@ <h2>Definitions of States and Properties (all aria-* attributes)</h2>
<li>Authors MUST NOT define an empty string value (<code>aria-actions=""</code>) on elements that do not have actions.</li>
<li>Authors SHOULD ensure that related actions elements are visible and activatable when the current element has DOM focus.</li>
<li>Authors SHOULD ensure the referencing element has <code>aria-actions=""</code> defined when not focused, if the related action elements do not exist in the DOM until the referencing element receives focus. This allows assistive technologies to surface the existence of actions outside of user interactions that trigger DOM focus.</li>
<li>User Agents SHOULD use the accessible names of elements referenced by <code>aria-actions</code> to determine the names of actions that are exposed in a platform accessibility API.</li>
<li>User Agents MUST use the accessible names of elements referenced by <code>aria-actions</code> to determine the names of actions that are exposed in a platform accessibility API.</li>
<li>User Agents MUST expose actions in the order that references are listed.</li>

@cookiecrook cookiecrook Jul 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is vague... I think you mean in the order of the IDREFs as listed in the aria-actions attribute, but this might also be read as the DOM order of the referenced elements.

@cookiecrook cookiecrook Jul 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, this should be a SHOULD, not a MUST, IMO.

<li>User Agents MUST expose an activation path to assistive technologies that performs the activation behavior of an element referenced by aria-actions without executing the default focus-transfer behavior associated with pointer activation.</li>

@jcsteh jcsteh Jun 5, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 mcking65 Jun 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 jcsteh Jun 10, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 mcking65 Jun 10, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@cookiecrook cookiecrook Jul 22, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

User Agents MUST expose an activation path to assistive technologies that performs the activation behavior of an element referenced by aria-actions without executing the default focus-transfer behavior associated with pointer activation.

This statement is difficult to understand. I'd recommend a single clear statement mention the click event on each actionable element, full stop.

Then specify the focus behavior elsewhere. Probably Core-AAM. The agreed upon approach also doesn't match what you've written here as rigid MUST statements. We agreed to implement the engine-internal focus bounce, and determine if/where there were edge cases. This statement over-constrains that development.

@cookiecrook cookiecrook Jul 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something like this:

Suggested change
<li>User Agents MUST expose an activation path to assistive technologies that performs the activation behavior of an element referenced by aria-actions without executing the default focus-transfer behavior associated with pointer activation.</li>
<li>When an assistive technology triggers an action, user agents MUST synthesize a pointer activation (`click`) on the referenced actionable element.</li>

<li>User Agents MUST NOT expose <code>aria-actions</code> if the Author MUST's are not followed.</li>

@cookiecrook cookiecrook Jul 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<li>User Agents MUST NOT expose <code>aria-actions</code> if the Author MUST's are not followed.</li>

To my knowledge, there's not precedent anywhere in W3C specs for this type of statement. It's not practically enforceable, and I would recommend dropping it altogether.

</ul>
</div>
Expand Down
Loading