ios a11y: a WKWebView exposes no element through idb — web content is a blind spot with no tree signal

[xxx]

Reading (2026-08-24)

iOS 26.5 Simulator, idb_companion 1.1.8 and 1.5.0b3, examples/ios-role-fixture launched with --tab web (a stock WKWebView on examples/web-role-fixture/index.html, rendered in full — screenshot checked):

• idb reports 2 nodes: AXApplication and AXGroup "Tab Bar". No AXWebArea, no page elements, and no element for the web view itself.
• Unchanged from t+2 s to t+30 s and after two taps inside the page.
• The Simulator's own Safari exposes browser chrome only on a rendered page.
• glass renders a 3-node tree with zero notices: there is no Document for document_guidance to fire on and no placeholder child for the unexposed-content notice.

Recorded on the role-support matrix as the iOS Document cell (unmarked); the unread AXWebArea iOS mapping was dropped (#517).

Why this stays open

Every other platform gives the tree some signal (a Document, or a null placeholder). iOS gives none, so closing this needs a signal that is not the tree — e.g. comparing what the tree covers against a non-blank window. That is a new mechanism and wants its own design; this issue holds the reading until then.

What would change the reading

An idb build (or a different reader) that reports AXWebArea for a WKWebView; a physical-device reading (only the Simulator was read).

[xxx]

Likely cause upstream: facebook/idb#901 ("Fix describe remote web content discovery", open as of 2026-08-24). Its description matches this reading exactly — idb ui describe did not enable remote-content discovery, and native traversal reporting near-full frame coverage starved the probe for embedded web content, so a WebView's subtree was never returned even when VoiceOver could reach it. glass's iOS reader goes through the same accessibility_info path.

What would close this: a companion built from that PR (or a release containing it) re-read against examples/ios-role-fixture --tab web — if the page's elements arrive under an AXWebArea, the iOS mapping and matrix cell come back and document_guidance covers iOS like the other platforms.

[xxx]

Read against a companion built from facebook/idb#901 (PR head dbb14f0, 2026-08-24, iPhone 17 / iOS 26.5 Simulator, same fixture):

• Control (brew 1.1.8, and idb main with #901 reverted): 2 nodes, as before — so #901 is the only thing that changes the reading.
• With #901: the first describe returns 12 nodes — 7 page nodes plus 3 leaked SpringBoard status-bar nodes. There is still no AXWebArea, no web root and no element for the WKWebView: page nodes land flat as siblings of the tab bar, marked only by a new per-node traits array containing "WebContent".
• What arrives is a 50 pt grid hit-test sample (gridStepSize=50, not client-settable): the paragraph, "not clicked", the textarea, one table header, one cell, the select. Missing: the <h1>, the link, the button, the text input, the checkbox, the iframe — so no tap and no set_value reading is possible.
• One-shot: the second and later describe calls return 4 nodes (page gone) until the companion process or the app is relaunched, so any act-then-verify loop cannot work.
• Side effects: the native Controls tab grows 18 → 21 nodes (status bar leaks in); describe latency roughly doubles.

Conclusion: keep the iOS Document cell unmarked; no glass change is warranted on this PR. Closing this still needs either a complete web tree from the companion (a real AXWebArea subtree, repeatable across calls) or a non-tree signal in glass.