Display
Diagram
A flow or architecture figure, drawn out of the system’s own parts.
When to reach for it
Examples
default
Notes
A flow or architecture diagram, drawn out of the system's own parts.
The alternative it replaces is a fenced block of box-drawing characters — ┌──────┬──────┐ — which is a picture rendered in a font chosen for code. It inherits the code block's frame and scrollbar, so a diagram reads as terminal output; it cannot wrap, so on a phone it either overflows or is scaled to nothing; the box edges are text, so a screen reader reads the rules out loud; and none of it responds to the theme.
The other alternative is a diagramming library, which is several hundred kilobytes of layout engine, renders after hydration, and draws in its own palette. This is neither: hairline frames on the radius scale, mono labels, the muted step for anything supporting — so a diagram belongs to the page it sits on. It server-renders, because it is markup.
NESTING IS CONTAINMENT, which is what most architecture diagrams actually describe: this is inside that, and these two sit beside each other. Edges are for the sequence between siblings, not for arbitrary wiring — a diagram that needs arbitrary wiring is a diagram that wants a drawing, and this will not pretend otherwise.
It takes a spec rather than markup, so a fenced ```diagram block in an article and a hand-written figure on a page are one renderer and one look — and a wrong diagram is corrected by editing data.
Props
| Prop | Type | Default | Description |
|---|---|---|---|
| specrequired | DiagramSpec | — | |
| className | string | — |
Accessibility
- A <figure> with role="group", named by its caption, so the whole picture is one thing a reader can skip.
- Arrows are aria-hidden: assistive tech reads the nodes in document order and has no use for a glyph pointing at the next one.
- Server-rendered markup, not a canvas — every label is real text a screen reader and a search engine can read.