Open Bug 1467382 Opened 6 years ago Updated 2 years ago

Support aria-keyshortcuts

Categories

(Core :: Disability Access APIs, enhancement, P3)

Product:
Core
Component:
Disability Access APIs
Type:
enhancement

Tracking

()

People

(Reporter: Jamie, Unassigned)

References

(Blocks 1 open bug)

Details

aria-keyshortcuts "Indicates keyboard shortcuts that an author has implemented to activate or give focus to an element." https://www.w3.org/TR/wai-aria-1.1/#aria-keyshortcuts We should expose this similarly to accesskey. Chrome already supports this. Simple test case: data:text/html,<div role="button" aria-keyshortcuts="Alt+Shift+f">foo</div> Note that Gecko has Accessible::AccessKey and Accessible::KeyboardShortcut. The latter is more for global shortcuts, but the distinction is unclear. I'd suggest we should just expose it from AccessKey (overriding the accesskey attribute if present).
If that's the case, we'll want to update the Core AAM. Please confirm and/or do a pull request to make the change: https://rawgit.com/w3c/core-aam/master/#ariaKeyhortcuts As for ATK, there's really no good place to put it, so the mapping is for an object attribute (and thus gotten "for free").

Ug. This is really tricky.

  1. Accessible::AccessKey and Accessible::KeyboardShortcut both return a KeyBinding, not a simple string. So, if we wanted to use one of these, we'd have to convert the object attribute value first.
  2. ATK maps accesskey to atk_action_get_keybinding, but aria-keyshortcuts to an object attribute.
  3. UIA maps accesskey to AccessKey, but aria-keyshortcuts to AcceleratorKey.

Joanie, you noted that for ATK, you can't (and thus don't) use atk_action_get_keybinding for aria-keyshortcuts. Can you explain why this is? Just trying to get a full understanding of the mappings before I figure out how to do this for Gecko.

Flags: needinfo?(jdiggs)

Other notes:

  1. For MSAA, we first try AccessKey and then KeyboardShortcut. We probably want aria-keyshortcuts to override accesskey. That means we can't expose aria-keyshortcuts as KeyboardShortcut, since accesskey would override it for MSAA.
  2. Chrome exposes aria-keyshortcuts via MSAA, overriding accesskey if present. It also exposes the keyshortcuts object attribute for both accesskey and aria-keyshortcuts.

Jamie: The actions exposed via AtkAction are things which an AT should be able to identify and also to invoke via the AtkAction interface such as clicking, pressing, expanding, activating, and -- unique to Gecko -- showing the longdesc.

In the case of aria-keyshortcuts, the spec says the keyshortcut can be to activate or to give focus to the widget. But we don't know which it is. That makes it harder to provide the reliably-identifiable-to-ATs aspect of an accessible action.

Also, unless an implementor is going to cause atk_action_do_action() to simulate/generate the keyboard event so that the author's code gets called, it provides no way for an AT to invoke it.

In addition, we're already getting it for "free" via object attribute, so it's easy enough for Orca to grab it that way -- even when the implementor hasn't added explicit support. So why insist on getting it via AtkAction? <insert shrug here>

That said, if you have solutions for these issues and plan to implement them, I could update Orca's code.

Flags: needinfo?(jdiggs)
Severity: normal → S3

I'll note here that the AXAPI mapping has been updated to AXKeyShortcutsValue: https://github.com/w3c/core-aam/pull/140/files

You need to log in before you can comment on or make changes to this bug.