Input modality support
The same task works by mouse, touch, stylus, keyboard, switch, or voice instead of assuming one way of operating the screen.
See it
What it is
Input modality support means the same task works with mouse, touch, stylus, keyboard, switch scanning, and voice commands. Pointer Events give mouse, pen, and touch a shared browser API, while semantic HTML, focus order, and accessible names cover the paths used by keyboards, switches, and voice control.
Build around the action rather than one device. A real button fires a click from mouse, touch, keyboard, and many assistive inputs. Hover can add a preview, but it cannot be the only way to reveal information or perform the action because touch and switch users may never produce it.
The gotcha is device detection. A Surface Pro, or an iPad with a Magic Keyboard and an Apple Pencil, switches from trackpad to finger to stylus in seconds, so classifying the whole device as mobile or desktop creates brittle branches. Use PointerEvent.pointerType only when the interaction truly needs different handling, and test every primary task through more than one path.
Ask AI for it
Refactor this interaction to support mouse, touch, pen, keyboard, switch scanning, and voice input. Use native button, a, input, and select elements for actions and form controls. Use the Pointer Events API for dragging, call element.setPointerCapture(event.pointerId) after pointerdown, and handle pointercancel without losing state. Provide a non-drag button-based path for the same action, keep all controls in logical Tab order, and make each accessible name contain its visible label. Remove hover-only actions and any permanent mobile-versus-desktop branch based on the first pointer type. List a test for mouse, touch, pen, keyboard, Apple Switch Control, and Apple Voice Control.