Accessibility and input methods are where cracks appear first

What it is

Between a cross-platform framework and the system, the first crack is not corner radius. It is the accessibility tree and the input method. A screen reader wants roles, names, focus order. An IME wants a contract among the composition window, candidate bar, uncommitted code, and caret. Self-drawn and wrapped controls both keep those contracts under the component API, easy to miss by default. Call the early failure a11y-IME fracture. People who never use VoiceOver or composing input may never see it. People who do hit a wall on the first try.

This is not “self-drawing drops scroll physics,” and not “the wrapper drifts on the long-press menu.” Those are behavior gaps a general user can feel. This is a deeper platform contract. Assistive tech and IMEs split first because they do not travel through ordinary hit-testing.

Why it happens

The system exposes accessibility as a tree parallel to views, and the IME as a session bound to a text control. A framework either bridges its own nodes into that tree (Flutter Semantics, RN accessibility props) or lets a wrapped native control speak for itself. The bridge is a second, hand-maintained UI: miss a role, and VoiceOver says “button” or nothing; focus follows paint order instead of reading order, and skip-reading breaks. IME composition (pinyin not yet committed) requires the control to understand “this stretch is not submitted yet.” A self-drawn editor that treats every key as a final character tears composition apart and lets the candidate bar drift.

The crack appears first because ordinary tests tap with a finger and type on a Western keyboard, exercising neither contract. CI stays green while VoiceOver and CJK input are already broken. They are canaries: what dies first is not the product’s face, but the two deepest layers of the platform contract.

Where it stops holding

A read-only tool that never takes text, and whose content is all system text controls, will not show the IME crack; the a11y crack can still open on custom drawing. If every operable object is a real system control and never enters a self-drawn tree, the crack returns to the system’s own quality and the framework is no longer the main cause. A game with its own narration and input is a different contract; do not measure it with the system tree. Internal tools whose known users never turn on assistive tech or composing input are low risk — until the first time they must.

Applying it

• Self-drawn operable objects must carry role, name, and focusability. Looking like a button is not a substitute for semantics.
• Route text editing through the system or the framework’s official input control. Do not take raw keys and concatenate strings.
• Put a screen-reader walkthrough and CJK / Japanese composition on every-release regression, beside tap tests, not after ship as feedback.
• Verify by completing the core task with a screen reader, listening, not looking. Any “unlabeled” or scrambled focus is an a11y crack. Then type uncommitted composing input in search and comment fields: the candidate bar should track the caret, and backspace should clear composition before committed characters. Either failure is not a one-off copy issue.

Related

• Same group: R4.14.1 Unified rendering buys visual consistency at the cost of system behavior · R4.14.2 Wrapping native controls produces drift in detailed behavior
• Adjacent: J2.09 Semantic structure · R4.03 Windows platform conventions
• Search terms: a11y-IME fracture · semantics bridge · IME composition