Neo4j Browser Graph Canvas and Assistive Technology: Limits of a Table Fallback

Neo4j Browser presents query results as an interactive graph drawn on an HTML5 canvas. Because canvas pixels do not expose per-node roles, names, or relationship information to the accessibility tree, keyboard-only and screen-reader users cannot traverse a returned graph the way they can traverse ordinary DOM content. The Cypher editor accepts keyboard input, but the surrounding result region offers no equivalent structured representation of the same data.

A frequently discussed remedy is a built-in table view that mirrors the graph result and stays keyboard navigable. The unresolved product question is whether such a view should become the default fallback when the canvas cannot be perceived, or remain an opt-in toggle. A parallel DOM representation for large graphs carries memory and rendering costs, and behavior may differ across Neo4j Desktop, Browser, and Aura console deployments.

Specific questions:

• Does the Neo4j 5.x series document any supported, keyboard-navigable alternative for graph results, or is the canvas the only first-party rendering path?
• If a table fallback is added, should it be default or opt-in, and what graph size threshold would make that choice practical?
• Which deployment targets would need separate verification for the same accessibility behavior?