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.