Keyboard, IME and accessibility

Integration

Interactive interfaces need keyboard focus, IME handling, selection state and accessibility semantics. Buttons, inputs and custom components should expose names and visible focus states. Check platform capabilities for the relevant version.

Constraints and troubleshooting

Complete real tasks with Tab, Shift+Tab, arrow keys and IME. Test disabled/hidden states, popups and window switching. Public accessibility structures and APIs do not prove acceptance by every platform assistive technology.

Examples and deployment requirements

Run the target package example, then check methods, fields and known issues for the same version. For optional backends, check manifest dependencies and enablement conditions.

• Find related entries →
• Read the extension deployment guide →

Current SDK keyboard limitation

In the Windows x64 SDK 3.61.7 lesson, Tab focuses the button, but Enter injected through DevTools does not trigger its save click. Mouse activation works. This does not establish behavior for every native keyboard path or full keyboard acceptance.

• Find keyboard limitations →

Keyboard and scaling checks

Verify a minimal scenario in this order before integrating the full application.

1. Traverse inputs and buttons with Tab/Shift+Tab and keep focus visible; label each field.
2. Vary scaling and width, checking clipping and access to key actions.
3. Check IME composition, selection, deletion and paste; editability alone does not establish accessibility support.
4. Use current observations for Enter activation and other behavior; documented lesson limitations remain limitations.