HTML virtualkeyboardpolicy: separate editing focus from the on-screen keyboard

A tablet worksheet may let someone select a cell to inspect its value before typing. Opening the keyboard on every selection can cover neighboring cells. Manual policy can support a separate “Type in this cell” action, provided the browser and device actually support the keyboard API.

Keep the default until manual control is available

Start with an editable region that works without the enhancement:

<p id="cell-label">Inspection note</p>
<div id="inspection-cell" contenteditable="true"
  role="textbox" aria-labelledby="cell-label"
  style="min-height:3em;border:1px solid;padding:12px">
  Replace the worn label before the next inspection.
</div>
<button id="type-in-cell" type="button">Type in this cell</button>

This gives the editing host an accessible name and usable target area. It does not save the note. Your application's existing document storage still needs to collect and persist the edited text; contenteditable behavior is separate from keyboard control.

After that markup exists, enable the manual policy only when the relevant interfaces are present:

const cell = document.querySelector('#inspection-cell');
const typeButton = document.querySelector('#type-in-cell');
const keyboard = navigator.virtualKeyboard;
const canRequestKeyboard =
  'virtualKeyboardPolicy' in cell &&
  typeof keyboard?.show === 'function';

if (canRequestKeyboard) {
  cell.virtualKeyboardPolicy = 'manual';
}

typeButton.addEventListener('click', () => {
  cell.focus();
  if (canRequestKeyboard) keyboard.show();
});

Without support, the button still focuses the cell and the attribute remains at its default behavior. The guard checks interface availability; it cannot establish that a device has a software keyboard ready to open.

Treat show() as a request

Call show() from the user's editing action after focusing the editable host. The API requires a secure context, and its behavior depends on activation, editable focus, keyboard policy, and platform restrictions. Do not use inputmode="none" on this host while expecting show() to summon text entry. Keyboard show requirements

The method returns undefined, so a truthy return value is not a success signal. If the layout needs the keyboard's bounds, use its geometry events and bounding rectangle. Do not label a successful JavaScript call “Keyboard opened” before observing the device's actual result.

Manual policy concerns the keyboard's opening behavior. It does not disable editing, validate the note, or choose its letter case. A separate capitalization hint may influence supported typing, while pasted text and saved records still need their own rules.

Check the device your worksheet will run on

Test the served page on a supported touch device over HTTPS. Select the cell, inspect whether the keyboard stays in its previous state, then use “Type in this cell” and type a short correction. Check that the caret, visible note, and any save action still work with the keyboard present. Restore automatic behavior if your target device cannot provide a reliable manual path.

Also test a browser without the API. The note must remain editable, and the control must not throw when clicked. A desktop Chrome check can confirm feature detection, focus, and text editing; changing a headless viewport to phone width does not verify a physical software keyboard.

Before shipping the worksheet, test with the actual device's keyboard attached and detached if both are expected. Keep the editing action understandable in each case, and save the corrected note through the worksheet's normal storage path.