This page covers the respondent-facing survey UI only. The Formbricks application that survey creators use
to build surveys, and the self-hosting and administration interfaces, have not been assessed to the same
standard and are not described here.
Standards We Measure Against
Formbricks assesses the public survey UI against two standards:
Our assessment is published as a Voluntary Product Accessibility Template (VPAT) using the VPAT 2.5Rev,
Revised Section 508 Edition format. The most recent report was completed on 9 August 2026.
To request the full report, ask in
GitHub Discussions.
Conformance Status
The public survey UI partially conforms to WCAG 2.0 Level AA. Partial conformance means that most of the standard is met, but some content does not fully conform. The known gaps are listed under Known Limitations below. We publish them rather than summarising them away, because a procurement team or an individual respondent needs to know what will not work before they rely on it, not after.The 9 August 2026 report and the current product have since diverged, in both directions. Three gaps the
report records as Partially Supports — page titles, the language switcher, and semantic headings — were
fixed in Formbricks 5.4; those entries are marked Fixed in 5.4 below. Image alt text and the top-level
heading on website and in-app surveys followed in 6.1, marked Fixed in 6.1. Two areas run the other way:
the report records them as supported, but a later review of the code found limitations we now publish below,
marked Not in the 9 August 2026 report. If you are assessing a version older than 5.4, the report remains
authoritative for the entries marked as fixed here; for the two areas it records as supported, this page is
the more accurate description.
Accessibility Features
Everything in this table was assessed as supported in the most recent report. Where a row carries an exception, it names it and links to the entry describing it.Known Limitations
The following do not fully conform. Each entry states what a respondent experiences and what a survey creator can do about it. Three markers say where an entry differs from the 9 August 2026 report. Fixed in 5.4 means the gap was closed in Formbricks 5.4, and Fixed in 6.1 that it was closed in 6.1; either way the workaround applies only to older versions. Not in the 9 August 2026 report means the report records that criterion as supported, and a later review of the code found otherwise.Image Text Alternatives
Affected criterion: 1.1.1 — Not in the 9 August 2026 report, Fixed in 6.1 Formbricks lets a survey creator add an image to a question or to an ending card. As assessed, those images were announced only as “Image”, with nothing about what they show, and a survey creator had no way to change that. Since 6.1, question images, ending card images and each Picture Selection option take alt text: select the Alt button on the image in the editor. It is translated per survey language like the headline. The text is read out as the image’s alternative. An image whose alt text is left empty is marked decorative, so a screen reader skips it instead of announcing a meaningless “Image”; a Picture Selection option without alt text is still named by position — “Option 1”, “Option 2” — so a respondent can tell the options apart. The field is optional, so whether an informative image is described is up to the survey creator. The welcome card’s logo and video both carry a fixed text alternative. Uploaded file names are never used as text alternatives, because a file name can carry personal data. Workaround for versions before 6.1: Without the field, treat question and ending images as illustration. Put anything a respondent needs in order to answer into the headline or the description, both of which are always read out. For a Picture Selection question, describe the options in the headline or description as well — for example “Option 1 is the blue design, option 2 the green one” — wherever the image carries the meaning.Embedded Third-Party Video
Affected criteria: 1.2.1, 1.2.2, 1.2.3, 1.2.5 Formbricks lets survey creators embed a video from YouTube, Vimeo, or Loom into a question. Formbricks provides no way to upload a transcript, add captions, or supply an audio description or text alternative for that video. A respondent who is deaf, hard of hearing, blind, or has low vision may not be able to access information that is only presented in the video. Adding captions on the hosting platform does not fully close the gap either, because Formbricks reduces the embedded player’s controls:
Every video carries an Open in new tab control in its bottom-right corner. It is reachable by keyboard and
becomes visible when it has focus, and it opens the video in the platform’s own player, where captions,
transcripts, and full playback controls are available. For a YouTube or Vimeo video, that is currently the only
route a respondent has to turn captions on.
Workaround: Repeat the essential information as text in the question headline or description — that is the
part that always works. Do not put information in a video that a respondent needs in order to answer the
question, unless that information also appears as text. Add captions and a transcript on the hosting platform as
well: for YouTube and Vimeo they will not be reachable from the embedded player, but they will be there for a
respondent who opens the video in its own tab.
Auto-Close Countdown
Affected criteria: 2.2.1, 2.2.2 — Not in the 9 August 2026 report. Applies only when a survey creator enables Auto close. Website and in-app surveys have an optional Auto close setting that dismisses an unanswered survey prompt after a set number of seconds. It is off by default, it is not available on link surveys, and it applies only to the survey’s first screen. With it off, nothing described here happens: there is no countdown, no automatic animation, and no time limit anywhere in the survey. With it on, the first screen carries a time limit — a respondent who needs longer to read the prompt than the configured number of seconds loses the survey. While the countdown runs it is shown as a shrinking progress bar, which animates for as long as the creator configured, and there is no control to pause, stop, or hide it. Formbricks does not cap the configured value, so that animation can run well beyond the five seconds after which an automatic animation needs a pause control. The countdown is cancelled by the respondent’s first interaction of any kind — moving the pointer over the survey, clicking, tapping, or pressing a key — and once cancelled it does not restart. A respondent who does anything at all keeps the survey. The respondent most likely to lose it is one who is reading or listening before touching anything, which includes screen reader users. Once past the first screen there is no time limit on answering. Workaround: Leave Auto close off, which is the default. If you need it, set it generously — long enough that a respondent reading at their own pace is not cut off.Page Titles and Survey Instructions
Affected criterion: 2.4.2 — Fixed in 5.4 As assessed, surveys carried no form title and survey instructions were not repeated after the welcome card, so a respondent using a screen reader was not given a clear description of the page they were on. A link survey now sets its document title per step, appending the respondent’s position — “Page 3 of 7” — to the survey’s own title, localized in the survey’s language. Where a survey has instructions, they are kept reachable on every page instead of disappearing once the respondent advances past the welcome card. The per-step document title applies to link surveys, which own the page they are shown on. A website or in-app survey is embedded in a page belonging to the site that shows it, and does not change that page’s title. Workaround for versions before 5.4: Write question headlines that make sense on their own, without depending on a title or on instructions given earlier in the survey.Current Language Not Identified in the Language Switcher
Affected criterion: 3.1.1 — Fixed in 5.4 As assessed, the language switcher was an unlabelled globe: it listed the available languages but gave no indication of which one was active, so neither a sighted nor a screen-reader respondent could tell what language the survey was being presented in. The switcher now names the active language, in that language rather than in translation — “Deutsch”, not “German” — both visibly and in its accessible name. Each option in the list carries its own language tag, so a screen reader pronounces every language name using that language’s rules. Workaround for versions before 5.4: For link surveys, thelang URL parameter sends a respondent straight to
the correct language, so they do not need to use the switcher. See
Multi-language Surveys.
Semantic Headings
Affected criterion: 2.4.6 — Fixed in 5.4; the top-level heading on website and in-app surveys is Fixed in 6.1. Website and in-app surveys use a generic top-level heading rather than the survey’s name. As assessed, the survey UI used no semantic heading elements, so a respondent using a screen reader could not navigate the survey by heading and question headlines were not exposed as headings. Card headlines — the welcome card, each question prompt, and the ending — are now second-level headings on every survey, so a respondent can navigate between them by heading. Every survey has a single top-level heading above them. On a link survey it is the survey’s name. A website or in-app survey is delivered by the JavaScript widget, which loads the survey from an endpoint that deliberately withholds survey names, so that a survey’s name is not readable by anyone who can reach that endpoint. The widget has no name to use, so it uses the generic label “Survey Dialog” instead:- Shown as a pop-up (the widget’s default): “Survey Dialog” names the dialog and is its top-level heading.
- Rendered inline into a container on the page: “Survey Dialog” is the top-level heading and names the form landmark, so the landmark is always named.
Language of Parts
Affected criterion: 3.1.2 Formbricks declares the survey’s language for the survey as a whole, and only when the survey has languages configured. Where a survey uses the multi-language feature, its root element carries alang attribute
resolved from the active language, updated when the respondent uses the language switcher — so an embedded
survey shown in a language other than its host page’s is still announced correctly, without Formbricks
altering the page it is embedded in. Link surveys additionally set lang and dir on the page’s <html>
element, so right-to-left languages read in the right direction.
A survey that does not use the multi-language feature has no configured language for Formbricks to resolve
from, so it declares no language of its own. It inherits whatever the surrounding page declares — the
respondent’s app locale for a link survey, or the host site’s lang for an embedded one. A survey written in
one language and opened where the page declares another is then announced using the wrong pronunciation rules.
The workaround is to enable the multi-language feature and set the survey’s language explicitly, even for a
survey that only ever needs one.
What a survey creator cannot do is mark up an individual passage. There is no way to set a language on a single
question, description, label, or choice option, and the language switcher’s own options are the only
individually tagged text in the survey. So where one screen mixes languages — an English question with an
untranslated choice option, or a term left in its original language — the part in the other language is not
programmatically identified, and a screen reader may pronounce it using the wrong language rules.
Workaround: Keep every part of a question in one language, and use the multi-language feature to offer the
whole survey in each language rather than mixing languages inside a single question.
Compatibility
The survey UI is built as a standard web application. It requires no plugin, no extension, and no separate accessible version, and it targets current versions of Chrome, Edge, Firefox, and Safari on desktop and on mobile. Our automated browser tests run on Chromium only, so the other engines are a design target rather than a tested guarantee.How the Assessment Was Carried Out
The most recent evaluation combined automated and manual testing:- IBM Equal Access Accessibility Checker — automated rule-based scanning
- ANDI (Accessible Name & Description Inspector) — inspection of accessible names, descriptions, and roles
- Manual testing — keyboard-only operation, focus order, and visual inspection