W3C home > Mailing lists > Public > public-aria@w3.org > February 2016

Mapping of aria-kbdshortcuts for ATK/AT-SPI2 and IA2

From: Joanmarie Diggs <jdiggs@igalia.com>
Date: Tue, 23 Feb 2016 15:02:16 -0500
To: IA2 List <Accessibility-ia2@lists.linux-foundation.org>
Cc: ARIA Working Group <public-aria@w3.org>
Message-ID: <56CCBAC8.4000507@igalia.com>
Hey all.

We need to come up with mappings for aria-kbdshortcuts for ATK/AT-SPI2
and IA2. And, unlike aria-errormessage, I got nothing (or almost nothing).

When the feature and question of mappings was first raised, I was
thinking it could be mapped via the Action interface. At least in the
case of my platform, that's where keyboard shortcuts are exposed. But
those shortcuts are associated with an action which can be performed by
the Action interface. And that's not the case with aria-kbdshortcuts. As
the spec states:

<quote>
Adding the aria-kbdshortcuts attribute to an element does not change the
behavior of the user agent by mapping the specified keyboard shortcuts
to the triggering of the element's activation function. It is still up
to the application to implement support for the keyboard shortcuts. The
aria-kbdshortcuts attribute exposes the fact that these shortcuts exist
so that assistive technologies can communicate this information to users.
</quote>

So if it's exposed via the action interface, we'd have the shortcut and
a name, but we'd have to know (and user agents would have to expose)
that the action might not be something we could actually perform. With
respect to the latter, on the surface it seems easy because, at least on
my platform, atk_action_do_action() returns a boolean reflecting
success. However, in practice, at least some implementors always return
true because they don't want performing an action to be blocking. In
other words, the return value is useless.

So.... Do we map this property via the Action attribute and just deal
with the fact that we cannot perform actions, or.... Something else?

--joanie
Received on Tuesday, 23 February 2016 20:02:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:20 UTC