Checking Your Activity’s Accessibility
As you edit, Doenet checks your document against the WCAG AA accessibility guidelines and reports what it finds in three connected places: a status indicator above the viewer, an accessibility report you can open, and inline marks in the code editor. This guide shows how to read all three and what the checks do — and do not — cover.
The checker tells you when your document violates a guideline. It cannot tell you whether your document is genuinely usable by someone who can’t see it — that part is up to you. For why that distinction matters, see Accessibility in Doenet. For the recipes that fix the issues below, see Writing Accessible Activities.
Read the status indicator above the viewer
Every Doenet editor shows an accessibility status indicator just above the rendered document. It has two states:
- Green — no WCAG AA violations were found.
- Purple, labelled “WCAG” — at least one WCAG AA violation was found.
The color tracks violations only. The example below is deliberately incomplete — a graph with no description and an input whose prompt is only ordinary text — so its indicator is purple. Run it and look above the viewer:
The sentence “What is the x-coordinate of P?” looks like a label, but it is just text sitting next to the input — nothing connects the two, so a screen reader announces the input as unlabeled. That, plus the undescribed graph, is two violations.
Open the accessibility report
Click the status indicator — or the Accessibility tab (marked with an accessibility icon and a count) in the editor’s footer — to open the accessibility report. The report has two lists:
- Accessibility violations (WCAG AA) — the problems that turn the indicator purple. Each entry names the line it is on and describes the fix. The heading links out to the official WCAG guidelines.
- Other accessibility issues — advisory recommendations that are not WCAG violations (more on these below).
For the example above, the first list reports two violations — one telling you the <graph> must have a short description (or be marked decorative), and one telling you the <mathInput> must have a short description or a label. When a list has nothing in it, it reads None found.
Fix the violations
Both violations are fixed by supplying the information only you can provide: a short description for the graph, and a label on the input. With those in place, the indicator turns green:
The <label> is now part of the input: it renders in the same place the sentence did, so the page looks the same, but it is programmatically tied to the input and a screen reader announces them together.
Green isn’t the whole story: advisories
The second list — Other accessibility issues — holds recommendations that don’t rise to a WCAG violation, so they leave the indicator green. A green indicator means “no violations,” not “nothing to improve.” It is worth opening the report even when the indicator is green.
A common advisory is a short description that contains mathematics. A screen reader reads a short description as plain text, so a <m> inside it is read out as raw notation. The graph below has a perfectly valid description as far as the violation check is concerned — the indicator stays green — but the report’s second list flags the embedded math:
Spelling the math out in words clears the advisory:
See the problems inline in the editor
The report lists issues by line, but you can also have Doenet mark them directly in the code. At the top of the accessibility report is a checkbox, Show accessibility diagnostics in editor. When it is on (the default), each flagged component gets a colored underline in the code editor; hover over the underline to read the same message the report shows. Turn the checkbox off to hide the marks while you work on something else.
What the checks cover
These are the accessibility checks Doenet runs today. The list is expected to grow over time.
| What you wrote | Result |
|---|---|
A <graph> or <image> with no short description and not marked decorative | Violation |
A <video> with no short description | Violation |
An input (<mathInput>, <textInput>, <choiceInput>, <booleanInput>, <matrixInput>, …) with no <label> and no short description | Violation |
An <answer> that creates its own input but has no <label> or short description | Violation |
A <styleDefinition> whose colors don’t have enough contrast against the canvas | Violation |
| A short description that contains math components | Advisory |
The violation checks are about whether the required information is present; the recipes guide shows how to supply it well. Color contrast is checked automatically for every style definition — see Styling, meaning, and accessibility.
What passing does and doesn’t mean
A green indicator means your document has none of the omissions above. It does not mean a screen-reader or keyboard user can actually complete your activity — a description can be present but useless, a label can be accurate but uninformative. Reaching zero violations is the right first step; the real work of writing descriptions someone can learn from begins there. See Accessibility in Doenet.
Where to go next
- Writing Accessible Activities — the recipes that clear these checks: descriptions, labels, links, headings, and tables.
- Accessible Interactive Graphs — making draggable graphs usable by keyboard and screen reader.
- Accessibility in Doenet — why the checker is a floor, not a ceiling.