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). Uploaded images on content blocks and heatmaps have an author-written Alt text field (translatable), and content-block images can be marked decorative (`alt=""`). Without author text the image is announced generically as "Image" — never by its file name — and Instrument Review raises an `image-missing-alt-text` warning. Conformance for a given survey still depends on the author writing meaningful descriptions.

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 state is never conveyed by color: required questions always carry screen-reader-only "(required)" text, authors can opt in to a visible asterisk glyph (Deploy → Structure; off by default), and a blank required answer produces a text error; validation errors render as text with `role="alert"`; card-sort selection state is exposed as `aria-pressed` on each card's button 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}` live on the drag handle. Card-sort's "select a card, then choose a category" path is also keyboard-operable: each card's label is a real `<button>` (with `aria-pressed` for its selected state), and each category has its own "Place here" button, so no interactive control is nested inside another. Rated Partial rather than Supports because keyboard operation has not yet been re-verified across every newer question type (e.g. tree testing, conjoint column headers).

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. When a respondent moves to another page, focus moves to the first question on the new page (the Next button they pressed is replaced), and when a page can't be submitted, focus moves to the first question that needs attention.

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. Each survey page has a single `<h1>` (the survey title, or a screen-reader-only "Survey" heading when the author hides the title), block names are `<h2>`, and the questions sit inside a `<main>` landmark.

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.

Surveys have no time limit unless the author turns on Timed Survey in the Deploy tab. When they do, the runner shows a visible "N left" countdown, announces a warning to screen readers at 1 minute and again at 20 seconds, and ends the response when time runs out. There is no way for a respondent to request more time. Research designs sometimes need a fixed limit (WCAG's "essential" exception), but without an extension option this stays Partial.

`<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 (text-response'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.