Skip to main content

Accessibility

The React UI ships with a baseline of keyboard and screen-reader support, and it is actively being improved. This page describes what works today and is honest about what is still partial โ€” accessibility is a work in progress, not a finished claim.

Canvas focus and rolesโ€‹

The drawing surface is focusable and announced as an interactive application region. DiagramSurface renders with tabIndex=0 and role="application" so keyboard users can Tab onto the canvas and screen readers announce it. Hosts can override the accessible name.

import { DiagramRoot, DiagramSurface } from "@oh-just-another/react-ui";

export function App() {
return (
<DiagramRoot>
<DiagramSurface ariaLabel="Architecture diagram" />
</DiagramRoot>
);
}

What's covered todayโ€‹

  • The canvas surface is keyboard-focusable with a visible focus ring.
  • UI chrome carries ARIA semantics: the toolbar, main menu, palettes, sliders, popovers, and color pickers expose aria-label, role="group" / role="radiogroup", and keyboard handlers.
  • Editing shortcuts (selection, nudging, undo/redo, etc.) are driven from the keyboard.
  • Keyboard-only creation: pick a shape tool (R, E) and press Enter โ€” the default shape lands at the viewport centre, selected.
  • Tab / Shift+Tab cycle focus through elements; each step is announced through the live region as name and position โ€” Selected Rectangle "Item 3", 2 of 10 (type plus label or text body, see getElementAccessibleName).
  • Palette items are focusable buttons named <name>, <geometry hint>, draggable (Decision, Diamond, draggable); Enter / Space places the shape at the viewport centre. Custom templates set the hint via Template.description.
  • The selection toolbar is a role="toolbar" named "Selection"; a multi-selection is described by its count and first three types (4 elements: rectangle, text, frame).
  • State is never colour-only: resolved comment pins carry a โœ“ glyph, and a selected connector gets a contrast ring around its accent halo (SELECTION_HALO_CONTRAST_STROKE).

Known gapsโ€‹

Because the scene contents live on a canvas (not in the DOM), there is no per-shape DOM node for a screen reader to traverse. Full assistive-technology coverage of individual shapes, comprehensive focus management across every panel, and complete keyboard parity for all pointer gestures are partial / in progress.

If accessibility is critical for your deployment, test with your target assistive technology and file gaps on the issue tracker โ€” improvements here are ongoing.