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.Some gaps recorded in the 9 August 2026 report have since been fixed in the codebase and will ship in the
next release. Those entries are marked Fixed, not yet released below and still read as Does Not Support
in the report, which predates the fix. If you are assessing a released version, treat the report as
authoritative for that version.
Accessibility Features
Everything in this table was assessed as supported in the most recent report.Website and in-app surveys have an optional auto-close setting that dismisses an unanswered survey
prompt after a set number of seconds. It applies only to the first screen, and the countdown is cancelled as
soon as the respondent interacts with the survey in any way — including with the keyboard. It does not
impose a time limit on answering, and it does not apply to link surveys. While the countdown runs it is
shown as a shrinking progress bar, which animates for as long as the creator configured — so a survey with
auto-close enabled does carry one automatic animation, and it can last longer than five seconds.
Known Limitations
The following were assessed as not conforming. Each entry states what a respondent experiences and what a survey creator can do about it. Entries marked Fixed, not yet released have been addressed in the codebase since the report was written and will ship in the next release; their workarounds still apply to released versions.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.
Page Titles and Survey Instructions
Affected criterion: 2.4.2 — Fixed, not yet released 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 released versions: 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, not yet released 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 released versions: 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, not yet released 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. The survey now has a heading structure: the survey name is its single top-level heading, and card headlines — the welcome card, each question prompt, and the ending — are second-level headings beneath it. A respondent can navigate the survey by heading and knows what they are answering. Workaround for released versions: Keeping surveys short and putting one question on each screen reduces the amount of navigation a respondent has to do.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