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 pressEnterโ the default shape lands at the viewport centre, selected. Tab/Shift+Tabcycle 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, seegetElementAccessibleName).- Palette items are focusable buttons named
<name>, <geometry hint>, draggable(Decision, Diamond, draggable);Enter/Spaceplaces the shape at the viewport centre. Custom templates set the hint viaTemplate.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.