Add browser requirements that support synthetic activation by AT#2806
Add browser requirements that support synthetic activation by AT#2806mcking65 wants to merge 1 commit into
Conversation
|
Discussed in today's ARIA meeting: https://www.w3.org/2026/06/04-aria-minutes.html#4500 |
| <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> | ||
| <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> |
There was a problem hiding this comment.
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.
Closes #2691
Note: Base branch is not main; it is the compare branch for #1805 (secondary-actions).