Keyboard Map

1. Introduction

On a KeyboardEvent, the code attribute encodes a value that represents the physical location of the key that was pressed. This value ignores the current locale (e.g., "en-US"), layout (e.g., "dvorak") and modifier state (e.g., "Shift + Control"), so it is ideally suited for applications (like games) that want to use the keyboard as a set of generic buttons. The idea behind the code attribute is that it provides a platform-neutral scancode for each physical key.

The key attribute, on the other hand, contains the value that is generated by the key press, accounting for the locale, layout, and modifier keys. Almost every Unicode character is a valid `key` attribute, along with a number of special named values (see KeyboardEvent key attribute values), so there are thousands of possible key values.

Because most users have a physical keyboard that matches their locale and layout, we can reasonably assume that the key value is a good stand-in for the glyph printed on the keycap. While this does not hold true when the user has selected a different layout, in that case the user is well-aware of the mismatch between the glyph on the keycap and the character generated by a key press.

The API described in this document provides a simple way of obtaining this basic code to key mapping.

2. Keyboard Map API

The Keyboard Map API extends the Keyboard interface to add attributes and methods related to the current keyboard layout.

2.1. Navigator Interface

The keyboard attribute on the Navigator object is specified in Keyboard-Lock.

2.2. KeyboardLayoutMap Interface

[Exposed=Window]
interface KeyboardLayoutMap {
  readonly maplike<DOMString, DOMString>;
};

2.3. Keyboard Interface

partial interface Keyboard {
  Promise<KeyboardLayoutMap> getLayoutMap();

  attribute EventHandler onlayoutchange;
};

Note: The base Keyboard interface is specified in [Keyboard-Lock].

navigator.keyboard.getLayoutMap().then(function(map) {
  var keyUp = map.get("KeyW");
  showUserDialog("Press " + keyUp + " to move up.");
});

2.4. Dead Keys and Combining Characters

Since the intent of the keyboard map API is to provide human-readable descriptions for keys on the user’s keyboard, dead keys or combining characters need to be converted into standalone forms so that they can be used directly.

The following table defines how to map from common dead keys and combining characters into standalone characters.

2.5. ASCII-Capable Keyboard Layouts

An ASCII-capable keyboard layout is one that:

• Is capable of producing all of the basic ASCII characters "A" - "Z" without requiring the use of any modifier keys.

• Produces a valid, printable character for all the common writing system keys.

The common writing system keys are those that are common to all keyboard layouts, as shown in blue in Figure 13 of the [UIEvents-Code] specification.

3. Keyboard Events

3.1. The layoutchange Event

When the user agent detects that the current keyboard layout has changed, then it MUST fire a layoutchange event. The exact timing of a layout change depends on the underlying platform but it is commonly triggered either directly by a user action (for example, when the user selects a new layout), or indirectly (such as when switching to an application that has a preferred layout).

Note the following:

• Modifying the set of available layouts should not trigger a layoutchange event, unless the modification changes the current layout.

• Adding or removing a physical keyboard should not trigger an event unless the system has functionality to change the current layout based on adding or removing a physical keyboard. But note that it is the layout change that triggers this event, not the act of adding or removing the physical keyboard.

• The event must be fired whenever the current layout changes, even if the highest priority ASCII-capable layout remains the same.

If the keyboard layout changes while the user agent is not the foreground application, then the user agent MUST fire a layoutchange event when it regains focus.

navigator.keyboard.addEventListener("layoutchange", function() {
  // Update user keyboard map settings
  updateGameControlSettingsPage();
});

4. Integrations

4.1. Permissions Policy

This specification defines a feature that controls whether the getLayoutMap() method is exposed on the Keyboard interface.

The feature name for this feature is "keyboard-map".

The default allowlist for this feature is "self".

5. Mobile Device Considerations

Since this is a keyboard-focused API and mobile devices do not commonly have physical keyboards, this API will not typically be present or supported on mobile devices.

However, mobile devices may choose to support this API if they allow physical keyboards to be connected. In this case, they may return a subset of the Writing System Keys that are appropriate for the platform.

Mobile platforms that require the user to configure their physical keyboard layout (and don’t provide a reasonable default), may support this API by returning a layout map that contains no entries.

6. Security Considerations

This API returns static data and does not change any system state, so there are no special security concerns.

7. Privacy Considerations

As with all APIs that return information about the current device state, there is a risk of using this API to create a larger "fingerprint" of the user than if this API was not available.

By returning info from the highest priority ASCII-capable keyboard layout instead of the active layout, the value of this information for fingerprinting is reduced since users are more likely to share the same values.

Note the following situations where this layout information might be used to identify individuals:

• Users who use uncommon ASCII layouts (like Dvorak or Colemak)

• Users who use an ASCII layout that doesn’t match the default for the region that they are in. For example, a user in the US with an active UK or French layout.

Without this API, similar fingerprinting can still be attempted, but it is more difficult since it would require the user to interact with the page by typing characters and analyze the resulting KeyboardEvents.

7.1. Privacy Mitigations

As a first line of defense for the user, this specification requires that the API is only available from secure contexts and can only be called from the currently active top-level browsing context or granted access via policy-controlled feature.

User agents that are concerned about the privacy impact of providing this keyboard mapping information can also consider the following mitigations:

• Having a user prompt to ask for permission whenever a site attempts to use this API.

• Always return a "standard" mapping. Although note that the standard mapping would need to vary for different parts of the world. For example, a user agent that had a "privacy mode" that always returned a US-QWERTY layout mapping would actually be providing more identifying information for users in the UK than the actual mapping would (since most users in the UK do not use a US layout).

7.2. Privacy Mode

If a user agent provides an "incognito" or "privacy mode", then this API should act the same as it does outside of "privacy mode". The reason for this is that there is no universal neutral value that can be returned to ensure the user’s privacy.

User agents may choose to give the user the option to specify what value should be returned when in this mode, although care must be taken to ensure that the user does not get a false sense of security since this value would need to be updated when if they travel outside their home region.

8. Acknowledgements

Thanks to the following people for the discussions that lead to the creation of this proposal:

Hadley Beeman (W3C TAG), Joe Downing (Google), Masayuki Nakano (Mozilla), Julien Wajsberg (Mozilla)

9. Glossary

scancode

A value that the keyboard hardware assigns to each key so that it can be identified uniquely. See https://en.wikipedia.org/wiki/Scancode for additional information.