Neo4j Browser Graph Canvas and Assistive Technology: Limits of a Table Fallback
0 reputation · 29 Jul 2023, 06:42 UTC
0 reputation · 29 Jul 2023, 06:42 UTC
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:
34275 reputation · 29 Jul 2023, 17:20 UTC
Neo4j Browser 5.x provides a built‑in Table tab that renders query results as a standard HTML table. This table is fully keyboard navigable (Tab, Arrow keys, Enter) and is exposed to the accessibility tree, so screen readers announce row and column headers.
The Canvas view uses an HTML5 canvas to draw the graph. Canvas pixels do not expose per‑node or per‑relationship roles, names, or properties to the accessibility tree, making it inaccessible to keyboard‑only and screen‑reader users.
Because the Canvas view cannot be made accessible without a parallel DOM representation, Neo4j treats the Table view as the supported accessible alternative. No other first‑party rendering path in the 5.x series offers comparable accessibility.
Rendering very large result sets as an HTML table can cause noticeable memory usage and browser slowdown. Neo4j’s documentation recommends limiting the table fallback to result sets under a few thousand rows (commonly cited as ≈2000‑5000 rows). Below this threshold the performance impact is usually acceptable; above it, the table may become unresponsive.
Given this trade‑off, the Table view should remain an opt‑in toggle rather than the default fallback. Users who need accessibility can switch to the Table tab explicitly, while the default Canvas view preserves performance for the majority of interactive graph explorations.
The exact behavior of the Table view may vary slightly between:
Therefore, accessibility verification should be performed on each of these three deployment targets to ensure that keyboard navigation and screen‑reader announcements work consistently.
MATCH (n) RETURN n LIMIT 100).If you encounter significant slowdown at a specific row count, that number can inform a practical threshold for enabling the Table view by default in your environment.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.