New ARIA attribute for possible interactions like delete, edit, move

[JAWS-test]

Many frameworks have widgets such as tabs (1, 2, 3) trees, or selection lists where the individual entries can be deleted, edited, or moved. This is - if implemented correctly - possible with the mouse or the keyboard (e.g. Delete key for deleting). The entries usually have buttons with e.g. a pen icon for editing or an x icon for deleting. Partly these buttons also get the focus with Tab. However, this does not lead to correct screen reader output, because elements with the ARIA roles tab, option or treeitem must not contain any other interactive elements.

However, there is currently no ARIA attribute to indicate these actions in the screen reader. Therefore I suggest that one is introduced and the necessary keyboard operation is defined, e.g.

• aria-action=delete, delete with the delete key
• aria-action=edit, edit with F2
• aria-action=move, move e.g. with Ctrl+arrow keys

Related but not the same: #762

[stes-acc]

Currently we help ourselves using custom attributing like "can be deleted" with hidden aria-describedby nodes but having a designated property would be very convenient.

What the proposal lacks is clarity if usage instructions should be always part of the proposed attribute. and if so, which formal grammar has to be obeyed to.

Grammar for key usage instruction could follow aria-keyshortcut rules.

Pattern:
aria-action="[custom action], [key usage instruction]"

Example:
aria-action="delete, Del"

[JAWS-test]

Grammar for key usage instruction could follow aria-keyshortcut rules

That would be a possibility. My suggestion was in the direction that only simple actions can be defined for which it is clear how they are to be operated, so that the keys do not have to be defined. Rather, screen readers can automatically output operating instructions, as they do for other interactive elements. Thus, the ARIA attribute remains platform-independent. I also find this useful because the shortcuts would not be noticeable to sighted keyboard users. In other words, it should be obvious to everyone how to perform the action.
More importantly, the screen reader must be able to perceive that an action can be performed. With aria-haspopup or aria-current it is also not conveyed how the pop-up is opened or the sorting is changed, but it is perceptible that it is possible

[stes-acc]

My suggestion was in the direction that only simple actions can be defined for which it is clear how they are to be operated, so that the keys do not have to be defined.

In my opinion, this would limit the scope of this attribute unnecessarily. It is also depending of the fact if the names of actions are just members of a typed enum or can be defined using any string.

I agree that keyboard instructions could be optional. But you will encounter situations where you may need them even if the default may be clear. For instance, F2 for entering an edit mode is not necessarily self evident.

[Malvoz]

There's a similar attribute here: https://w3c.github.io/personalization-semantics/content/#action-explanation.

[Mattias-Martens]

https://w3c.github.io/personalization-semantics/content/#action-explanation is a dead link unfortunately.

i am also curious about this.

[Malvoz]

It was moved to https://www.w3.org/TR/adapt-content/#action-explanation.

[spectranaut]

hey @smhigley just noticed this issue is another "secondary action" (#1440) issue, I wonder if you have a list of these somewhere.

[scottaohara]

the solutions to these would likely all fall under the scope of the secondary action proposal. i don't think there'd be much reason to do something specifically for these in addition to that. good calls outs here though, but we can probably close this per the linked issue where that'd be the final solution.

[spectranaut]

Cool, closing as duplicate of the secondary actions proposal: #1440