Accessibility (WASM host)

Moving logic to Rust does not outsource accessibility: the accessible tree still comes from the DOM (or your replacement strategy).

Overview

Complement Editor → Accessibility. For typical hybrid editors, WASM handles data; the view must expose correct roles, names, and focus moves for keyboard and AT users.

Browser as host surface

With contenteditable, assistive tech interacts with the same DOM you mutate from JS. If Rust drives all structure via patches, ensure updates preserve stable landmarks (headings, lists) where possible.

Roles & labels

Toolbar buttons need labels; the editable region may need aria-multiline, instructions, or live regions for collaboration status—policy belongs in the UI layer even if copy comes from WASM.

Focus management

Custom toolbars and modals must not steal focus without restoring the caret; WASM callbacks that trigger re-renders should be sequenced so focus is not lost mid-IME session.

Canvas-only editors need explicit accessibility mappings (e.g. separate off-screen input or ARIA canvas patterns)—much heavier than DOM-hosted editing.

What WASM does not fix

Screen reader behavior for complex widgets is still dominated by browser and AT heuristics. Test with VoiceOver, NVDA, and mobile TalkBack on real devices.