Goals:
- Consensus on user agent requirements.
- Consensus on authoring requirements.
- Establish starting point for screen reader interoperability tests and assertions.
- Editor's draft of aria-actions in Accessible Rich Internet Applications (WAI-ARIA) 1.3
- Pull Request: feat: aria-actions addition to the ARIA spec by smhigley · Pull Request #1805 · w3c/aria
- Issue: Secondary actions on items in composite widget roles · Issue #1440 · w3c/aria
- TPAC 2024 ARIA Meetings · w3c/aria Wiki
User Agents SHOULD use the accessible names of elements referenced by aria-actions to determine the names of actions that are exposed in a platform accessibility API.
Q1. If an element has both aria-details and aria-actions, which relation takes precedence, i.e., which relation must user agents expose?
- Example: popup trigger has aria-actions specified.
- Propose a user agent requirement to ensure consistent implementation of precedence.
Q2. Must user agents expose aria-actions in the order the IDs are specified by the author?
- Authors need a way to control presentation.
- Propose a user agent requirement for ordering.
Q3. To which descendants must user agents propagate aria-actions?
- All accessible descendants except for elements with roles that do not support aria-actions?
- Propose a user agent requirement to ensure consistent exposure of inherited actions.
Q4. When an element has both its own and inherited actions, in what order must user agents expose the actions?
- current element then ancestors in order of increasing distance?
- Example: element inside cell, then cell, then row, then rowgroup?
- Propose a user agent requirement for ordering of inherited actions.
Q5. When an element has a combination of inherited and its own action and detail relations, which ones take precedence?
- Propose user agent relation precedence requirements cover both inherited and directly owned relations.
- Authors MUST ensure that elements referenced by aria-actions have an accessible name.
- Authors MUST ensure that related action elements respond to a click event and are not limited to modality-specific activation such as the keyup or touchend events.
- Authors MUST ensure each referenced action element is either directly navigable with the keyboard or that there is a keyboard shortcut to directly activate it when focus is on the referencing element.
- Authors SHOULD ensure that related actions elements are visible and activatable when the current element is focused by the user agent or assistive technology.
Q1. Is there a difference between being focused by a user agent and focused by an assistive technology?
- If yes, how can authors detect assistive technology focus?
- If no, why are assistive technologies mentioned in the 4th requirement?
Q2. Is there a difference between the current element and the referencing element?
- If yes, what is the difference?
- If no, should the 4th requirement specify the referencing element instead?
Q3. If aria-actions are specified on an element that is not focusable, when must authors make referenced elements visible and activatable?
- when focus is inside the referencing element?
- If the referencing element does not contain focusable elements, are actions permitted?
Q4. If the name of an element referenced by aria-actions is not sufficiently distinct, how can authors specify a unique name?
- Example 1: dialog references its close button and a tab inside the dialog references its close button.
- Example 2: A region references a button with aria-expanded that has the same name as the region it controls.
- Propose aria-actionlabel that can be applied to an element referenced by aria-actions.
Q5. Should the burden of ensuring unique action names fall entirely on authors?
- Must authors walk up the tree to discover inherited actions?
- How would authors be able to discover if two actions have the same computed name?
- Should authors modify inherited actions, e.g., remove or rename them?