Need way to determine what keys are supported on device.

[garykac]

Copied from W3C Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19771

Glenn Adams 2012-10-30 06:43:02 UTC

On devices that use RCs (remote controls), it is often the case that the set of supported keys vary. For example, one RC might have red, green, blue buttons, while another might have red, green, blue, yellow. There is also much variation in supported keys for media related functions and other device specific extensions.

At present DOM-3 Events does not specify that any particular physical key must be supported on a device. But rather, simply defines which key values are to be used when a key is present. [Though even this is ambiguous since if some physical key is present, there is nothing in DOM-3 Events which mandates a specific key (string) value be used.]

In order to address this, I suggest defining an appropriate API in DOM-3 Events, e.g.,

partial interface Navigator {
   DOMString? getKeyLabel(DOMString keyString, optional DOMString locale);
}

The method getKeyLabel() returns a non-empty string that denotes a device dependent label for a key that generates keyString, or, if no key generates keyString, then returns null. If locale is specified and non-empty, and if a locale specific label is available, then it should be returned instead of a default label.

The returned label should be suitable for presentation to the end-user in a user interface in order to indicate to the user the label of the key found on the (physical or virtual) key.

In all cases, either a non-empty string or null shall be returned.

It might also be desirable to provide an additional method, such as:

partial interface Navigator {
   DOMString[] getKeyStrings();
}

which returns all key strings supported by the device [that could be used as an argument when calling getKeyLabel()].

This latter would be useful for making effective use of keys for which no standard key string has yet been published.

Comment 1 Hallvord R. M. Steen 2012-11-02 08:28:57 UTC

The implementation should have some protection against fingerprinting, for privacy reasons.

Comment 2 Gary Kacmarcik 2013-05-17 16:42:19 UTC

We're trying to do something similar with queryKeyCaps in UI Events.

Since this certainly won't be part of D3E at this point, I'm changing the component to "UI Events" so we can consider it for that spec.

[chaals]

This could be very helpful. One of the problems it runs into is working with IMEs. Another is straight-up keyboard switching, as I do on some devices. In particular when using an external keyboard plugged into a television, is the information available to the platform?

Another concern (to go with fingerprinting) is whether a user can effectively make use of all the keys on a device - for example, an eye-tracking user may be simulating keyboard events and may even have a real keyboard connected to the device, but it may be difficult or impossible to determine whether the user has a given key.

[garykac]

This issue has been addressed by Keyboard Map API

https://wicg.github.io/keyboard-map/