Our WCAG 2.1 A/AA accessibility self-assessment.

Per-cell aria-labels are present on grid-matrix and slider inputs (verified in grid-matrix-renderer.tsx / slider-renderer.tsx). Heatmap and informational-block images fall back to the uploaded file name as alt text (e.g. `alt={img?.fileName || "Heatmap"}`) — there is no author-facing field to write a real description, so an uploaded image's alt text is only as meaningful as its file name.

Question titles act as programmatic labels; validation errors are associated via `aria-describedby`/`aria-invalid` (verified in short-answer-renderer.tsx, dropdown-renderer.tsx, constant-sum-renderer.tsx); native form controls (radio/checkbox/select) are used for choice-based questions rather than custom unlabeled divs.

Confirmed via the live axe scan across all six audited renderer types — no violations related to DOM/visual order mismatches.

Required fields are marked with a visible asterisk glyph (not color alone); validation errors render as text with `role="alert"`; card-sort selection state is now stated in the drag-handle's `aria-label` text as well as a ring/border color change.

The default "void" and "nice" themes use the app's own design-token palette, which was built with contrast in mind, but has not been run through automated contrast tooling end-to-end. Authors can also set fully custom theme colors per survey (`SurveyTheme.colors`) — Domandata cannot guarantee an author-chosen color combination meets contrast minimums, and no linting or warning currently flags a low-contrast custom theme.

No `maximum-scale`/`user-scalable` viewport restriction is set (`src/app/layout.tsx` only sets `colorScheme`), and question/answer typography uses relative (rem/Tailwind scale) units rather than fixed pixel sizes that would clip on zoom.

The public runner and its renderers use responsive Tailwind layout throughout; grid-matrix specifically has an author-toggleable "mobile-friendly layout" mode for narrow viewports.

Default themes use the app's token border/ring colors, which were designed with contrast in mind, but the same custom-theme caveat as PCV-05 applies — an author-set custom accent or border color is not automatically checked against its background.

Drag-to-order and card-sort both work end-to-end with a keyboard via dnd-kit's `KeyboardSensor` (Tab to the grip handle, Space to pick up, arrow keys to move, Space to drop) — verified in drag-to-order-renderer.tsx and card-sort-renderer.tsx, where `{...attributes}{...listeners}` (which supply the focusable role/tabIndex/keydown handling) live on the drag handle. However, card-sort's mouse/touch-only "tap a card to select, then tap a category" shortcut (`DraggableCard`'s `onClick` select and `DroppableZone`'s `onTap`, both in card-sort-renderer.tsx) has no keyboard equivalent — it is a convenience path, not the only way to complete the question, since the native dnd-kit keyboard drag still works, but it is not itself keyboard-operable. Rated Partial rather than Supports until that tap target gets a keyboard-accessible equivalent.

No modal-style focus trap exists in the audited renderers; dnd-kit's keyboard drag mode releases focus normally on drop or Escape.

Confirmed via the live axe scan across all six audited renderer types — no focus-order violations.

Renderer-generated UI has no ambiguous links. Question titles and custom-HTML blocks are author-written content (sanitized, not authored by Domandata) and can include arbitrary links — their purpose is the survey author's responsibility, not something the runner enforces.

Question titles double as the associated label for their answer control; block/question titles are author-supplied but structurally always present as the label element, not decorative text.

Focus-visible ring styling is applied through the shared UI primitives (e.g. `focus-visible:ring-2 focus-visible:ring-ring/50` used across footer/nav links and form primitives). One real gap was found and fixed during a manual tab-through audit (2026-08-28, not something the automated axe scan catches): the slider's underlying native `<input type="range">` is `opacity-0` to let a custom-styled track/thumb render on top, which also hid its native focus ring with no substitute — a keyboard user tabbing to any slider had no visible focus indicator at all. Fixed in `slider-renderer.tsx` via a Tailwind `peer-focus-visible` ring on the visible thumb, verified with a before/after screenshot showing the ring appear on Tab. Not exhaustively re-verified against every author-defined custom survey theme, since custom CSS can in principle override focus styling.

Grid-matrix per-cell `aria-label`s are built directly from the visible row/column text (`{row}, {colLabel}`), so the accessible name is a superset of what's visually shown, not an unrelated string.

Slider's draggable hit area (the invisible native `<input type="range">` spanning the full track) was widened from 20px to 44px tall (`slider-renderer.tsx`, 2026-08-28), verified visually and against the automated suite. Not exhaustively verified for every other custom control across every theme, so still rated Partial overall rather than Yes.

The public survey runner (`FlowConfig.structure`) has no built-in respondent-facing countdown or session expiry that would end a response early; `capturePageDwellTime` only records elapsed time for research purposes and never limits it. Not applicable in the current product.

`<html lang="en">` is set at the root layout, and the public survey client runner updates `document.documentElement.lang` to the respondent's active survey language at runtime (`public-survey-client-runner.tsx`) for surveys using the multi-language / RTL feature.

No renderer in the audited set navigates, submits, or opens new context on focus alone; advancing the survey always requires an explicit Next/Submit action.

Selecting an answer never auto-advances the page or auto-submits the survey; the respondent always reaches the next page through the visible Next/Submit control.

Required-field and validation errors render as visible text with `role="alert"` and are tied to their control via `aria-describedby`/`aria-invalid` (verified in short-answer-renderer.tsx and others).

Every question renders its title as a visible label, plus author-optional instruction text (e.g. card-sort's `config.instructions`, drag-to-order's static "Drag the handle to rank in order" hint).

Some renderers give a specific, actionable message (short-answer's character-count-over-limit text); others state only that the field is required (e.g. card-sort's "Sort every card into a category before continuing") without a more granular suggestion. Not inconsistent enough to call broken, but not uniformly best-practice either.

React/JSX's compile step structurally prevents unclosed-tag and malformed-nesting errors; this criterion is largely superseded by modern HTML5 parsing behavior (dropped entirely in WCAG 2.2) but is included here since we scope this assessment to 2.1.

This is the exact criterion the live axe scan caught two real regressions against: a progress bar with no accessible name (`aria-progressbar-name`, serious) and an invalid `aria-pressed` on a plain, roleless `<div>` in card-sort (`aria-allowed-attr`, critical). Both are fixed as part of this same change — the progress bar now has `aria-label={`Survey progress, ${Math.round(percent)}% complete`}`, and card-sort's selected state moved into the drag handle's existing `aria-label` text instead of an invalid ARIA attribute on a non-interactive div. A re-scan after both fixes showed zero violations across all six audited renderer types.

Validation errors use `role="alert"` and card-sort's tap-to-select state uses `role="status"` in the six renderer types covered by the automated scan. This has not been audited across every status-style message in the rest of the app (e.g. toast notifications, save confirmations outside the survey runner), so it is disclosed as partial rather than a blanket yes.

No formal, externally-produced VPAT or third-party accessibility audit has been performed. This page is a Domandata self-assessment backed by an automated axe-core scan of six renderer types, not an independent audit. Open item, disclosed honestly rather than implied otherwise.

No documented manual screen-reader test pass exists. Current coverage is automated (`@axe-core/playwright` against six renderer types, gated in CI on every PR into `main` — see docs/accessibility-compliance-runbook.md) plus ad hoc aria attributes verified by code review; it has not been exercised with a real screen reader by a human tester.