Accessibility And Input

Graphora's first renderer is Canvas 2D. Canvas is useful for graph drawing, but it does not expose every node and edge as semantic DOM by itself. Applications should treat accessibility as part of the surrounding product UI, not something the Canvas can solve alone.

Current Responsibilities

Graphora currently provides:

• renderer picking for graph targets
• pure hover, selection, drag, pan/zoom, click, lasso, context-menu, and tooltip helpers
• shared opt-in keyboard and focus helpers with editable-target protection
• app-owned vanilla examples that wire DOM events to those helpers
• status/menu/tooltip DOM in examples where the UI belongs outside the renderer

Applications currently own:

• graph container labels
• keyboard listener wiring
• screen-reader-friendly summaries or details panels
• menu and tooltip DOM
• focus management and announcements
• touch gesture policy

Canvas Limitations

A rendered graph can be visible and interactive without being fully accessible to screen readers. If graph items are important for non-pointer workflows, provide companion DOM such as:

• a node or edge list
• selected item details
• an inspect panel
• search results
• command buttons for fit, clear selection, and inspect
• a status region for interaction feedback

Keyboard And Focus

Keyboard behavior is available through opt-in helpers. Focus, selection, hover, highlight, and drag remain separate states:

• focus is the current keyboard or programmatic item target
• selection is the user's selected item set
• hover is a transient pointer target
• highlight is visual emphasis
• drag is an active pointer gesture

Default shortcuts should be disableable and should ignore text inputs and other editable DOM by default.

Shared focus and keyboard helpers now live in @graphora/interactions. The vanilla interaction and React callbacks examples demonstrate opt-in shortcuts, node/edge focus and editable-target protection using the same example adapter. Graph-container DOM focus and the current graph item remain separate. Arrows change item focus, Space changes selection, Enter fits focus, f fits selection, Escape clears selection, Shift+Escape clears focus, and Tab leaves the surface. The navigation filter limits candidate IDs; it does not hide graph data.

These workflows have Chromium coverage. A live status output describes focus, but there is no general semantic node/edge tree or screen-reader certification. Applications remain responsible for custom editors, shadow-DOM event policy, companion views and appropriate keyboard ordering.

Context Menus And Tooltips

@graphora/interactions creates context-menu and tooltip intent payloads from renderer pick results. Applications render the actual UI.

Use semantic DOM where helpful:

• role="menu" for app-owned context menus
• role="menuitem" for menu actions
• role="tooltip" for tooltip surfaces

Keep async loading, dismissal, focus management, and error states in the application layer.

Touch

Touch behavior is not complete yet. Applications should decide whether a graph surface owns page scroll, one-finger pan, node drag, long press, and pinch zoom. Examples may use touch-action: none when the graph intentionally owns the gesture surface.

Minimap

Future minimap work should provide an accessible label and should not be the only way to navigate the graph. Keyboard and screen-reader alternatives should exist through app-owned controls or companion UI.

Quality Bar

Before adding a new interaction feature, check:

• Can pointer-only behavior be avoided or documented?
• Does the feature preserve separate hover, selection, focus, highlight, and drag state?
• Is the DOM or framework UI app-owned when semantics matter?
• Can applications disable or customize keyboard behavior?
• Are Canvas limitations described honestly?