A whiteboard is two accessibility problems wearing one interface. There is the editor, which somebody has to be able to operate, and there is the diagram, which somebody else has to be able to read. They fail independently, they are fixed by different people, and a report that treats them as one subject will be useless to at least one of those people.
You can watch a vendor make the distinction with their own tooling. Miro's published accessibility changelog describes fixing false positives in its built-in accessibility checker, for connectors intersecting shapes, text intersecting shapes, and frame titles inside slide containers. Every one of those is a check on the board somebody drew, not on the editor they drew it in. The product ships a tool for the second problem because the second problem is real and separate.
What Auditing the Editor Actually Means
The scale is worth being honest about. That same changelog records an audit in early 2026 that identified 188 issues across 21 areas of the product, with nearly 50 engineers contributing to the fixes. That is the vendor's own account of their own work, dated, not our finding and not a description of the product today. It is a fair indication of what a canvas application contains.
So the operation matrix below is not a checklist you run in an hour. It is a scoping instrument, and its job is to make the size of the work visible before anybody agrees a price.
| Operation | Pointer with drag | Pointer without drag | Keyboard |
|---|---|---|---|
| Create a shape | Drag from a palette | Required alternative, often a click-then-click | Required separately, often a command palette |
| Select one object | Click | Same thing | Needs an order to move through |
| Select several | Drag a marquee | Required alternative, such as tap-to-add | Modifier plus the same order |
| Name or label an object | Double-click to edit | Same thing | Enter or a menu route |
| Connect two objects | Drag from anchor to anchor | Required alternative | A dialog naming source and target |
| Move an object | Drag | Required alternative, such as numeric position or cut and place | Arrow keys, ideally with a step size |
| Resize | Drag a handle | Required alternative, such as a numeric field | Arrow keys with a modifier |
| Reorder or change layer | Drag in a list | Required alternative | A menu command |
| Group and ungroup | Menu, usually | Same thing | Same thing |
| Delete | Menu or key | Same thing | Delete key, with the deletion announced |
| Comment | Click a spot then type | Same thing | Needs a route to the anchor point |
| Pan and zoom | Drag the canvas | Required alternative, such as buttons | Keys, plus a way to know where you are |
| Export | Menu | Same thing | Same thing, plus the output question below |
Why the Two Pointer Columns Are Not One Column
Dragging Movements is new in WCAG 2.2 and it is the criterion this whole category answers to. It requires that any functionality using a dragging movement can also be achieved by a single pointer without dragging, unless dragging is essential, or unless the behaviour comes from the browser and the author has not modified it.
A dragging movement is defined by four actions. Establish a start point, press and hold, reposition, release. The direction and the route of that repositioning do not matter, which is what separates this criterion from the one about path-based gestures, and the reason is technical rather than arbitrary. The browser retargets every subsequent pointer event to the element that was pressed, wherever the pointer travels.
A keyboard route does not satisfy this criterion
This is the misreading that gets whole editor audits wrong. Keyboard access is required by a different rule, and providing it does not answer the dragging criterion, which asks specifically about a single pointer. Somebody using a head pointer, a joystick or a touchscreen with limited dexterity is a pointer user who cannot drag. Building a beautiful keyboard command palette and calling the drag question closed leaves those users exactly where they were.
The good news is that the alternative has more freedom than teams expect. W3C's sufficient technique and its failure technique both say the non-drag route can be several single-pointer interactions in a row rather than one control that does the whole job. The alternative does not have to be the same component, so equivalent functionality elsewhere on the page counts. And a text input beside a control is a legitimate answer, because on a touchscreen the on-screen keyboard is itself pointer-operated.
One thing the alternative cannot be is a swipe or a flick, because a path-based gesture fails the pointer gestures criterion instead. Replacing one gesture with a different gesture is not progress.
What Is Out of Scope, and What Is Not Automatically In
Two boundaries stop this criterion from swallowing the whole interface.
The first is that browser scrolling is the browser's business. Dragging a scrollbar, dragging a touchscreen page, pull-to-refresh and CSS overflow scrolling are all the user agent's responsibility. Panning a canvas that the author built is a different thing, because the author built it.
The second is the essential exception, and it needs to be argued per operation rather than claimed for the application. "It is a canvas" is not an exception. Freehand drawing may genuinely be essential, because the position of every point is the content. Moving a box from one column to another is not, because the same result is a menu command away, and W3C's failure technique names list re-ordering and a kanban board as its two examples. Neither of those is a whiteboard, which is exactly why the analysis has to be done operation by operation.
It follows that canvas rendering by itself establishes nothing. A canvas element with a full set of keyboard commands, an accessible object list and non-drag alternatives can be perfectly usable. A pile of DOM nodes with drag-only interaction cannot. The technology is not the finding.
The Second Question, Which Nobody Scopes
Now the diagram itself, which is the part that reaches an audience. A finished diagram is non-text content, and it usually carries information that exists nowhere else in the document, which puts it in the hardest category of Non-text Content rather than the easiest.
For an image whose meaning cannot be carried by a short sentence, the standard asks for two things together. A short text alternative that gives a brief description, and a long description reachable some other way. Both, not either. Our charts guide works through what a long description contains, and the same reasoning applies to a process diagram or an architecture drawing.
| What is produced | The question | Who owns it |
|---|---|---|
| A board people are invited to | Can a reader who cannot see it get the structure and the content | Your team, and partly the editor's object model |
| An exported image | Does it carry a short alternative and a long description wherever it lands | Whoever pastes it into the document |
| An embedded board in a wiki or doc | Is the embed reachable, and is there a text equivalent beside it | Whoever embedded it |
| A printed or PDF export | Is it tagged, and is the diagram described | Covered by our PDF guide |
| Shapes with no labels | Does the object list say anything meaningful | The person who drew it, every time |
That last row is the one worth taking back to the team. An editor can expose a list of objects, and it cannot invent names for them. A board of forty unlabelled rectangles is a board of forty items called Rectangle, whatever the vendor does, and no audit finding will fix it. That is a working practice, and it is cheaper than any of the alternatives.
What to Settle Before an Editor Audit Starts
- Which operations are in scope. The matrix above has thirteen. A scope that names five of them is a scope somebody can price and deliver.
- Which boards. A blank board, a small real one and a large real one behave differently, and a large board is where performance and virtualization problems appear.
- Which input methods. Pointer with drag, pointer without drag, keyboard, and whether speech input is included. Speech is a separate arrangement rather than an assumption.
- Whether the output layer is included. It is a different piece of work with a different owner, and it is worth doing, and it should be agreed rather than smuggled in.
- Whose findings are whose. Most editor findings belong to the vendor. Say so up front and the report lands better.
One honest limit
We audit and never repair, so this is not an offer to build a non-drag route into anybody's canvas. We have not operated any editor for this page, and a vendor's own changelog is their record rather than our finding. A complex editor is a scoping conversation before it is a quote, because thirteen operations across four input methods is not a fixed-price page count. Start it at contact or read what the web app audit covers.