> ## Documentation Index > Fetch the complete documentation index at: https://formbricks.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Accessibility > How the Formbricks survey UI supports respondents with disabilities, which standards we measure against, and where we currently fall short. Formbricks is used to ask people questions. A survey that some people cannot answer is a survey that returns incomplete data, so accessibility is not a compliance exercise for us — it is part of the product working correctly. This page describes the accessibility of the **public survey UI**: the interface a respondent sees when they open a link survey or are shown a website or in-app survey. It covers what already works, what does not, and how to reach us. > [!NOTE] > > 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: | Standard | Level assessed | | - | - | | Web Content Accessibility Guidelines (WCAG) 2.0 | Level A and Level AA | | Revised Section 508 standards (published 18 January 2017, corrected 22 January 2018) | Chapters 3, 5 and 6 | 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](https://github.com/formbricks/formbricks/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](#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. > [!NOTE] > > 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. | Area | What the survey UI does | WCAG 2.0 criterion | | - | - | - | | Keyboard operation | Every question type, navigation button, and control can be operated with a keyboard alone. Keyboard focus is never trapped in a component — it can always be moved away using standard keys. | 2.1.1, 2.1.2 | | Visible focus | The element that currently has keyboard focus is shown with a visible focus indicator. | 2.4.7 | | Focus order | Focus moves through the survey in an order that preserves meaning and operability. | 2.4.3 | | Contrast | Text and images of text in the default survey theme meet the minimum contrast ratio. A survey creator can override every colour, and Formbricks does not check the contrast of a custom theme. | 1.4.3 | | Resizing text | Text can be resized up to 200% without assistive technology, and without loss of content or functionality. | 1.4.4 | | No time limits | There is no time limit on completing a survey, except when a creator enables [Auto close](#auto-close-countdown), which is off by default. | 2.2.1 | | No auto-playing media | No audio or video ever plays on its own. The [Auto close](#auto-close-countdown) countdown is the only thing that animates by itself. | 2.2.2 | | Error identification | When an answer is rejected, the error is identified and described to the respondent in text. | 3.3.1 | | Error suggestion | Where we know how an input should be corrected, the survey suggests the correction. | 3.3.3 | | Labels and instructions | Every input field has a descriptive label. | 3.3.2 | | Review and correction | A **Back** button is shown by default, so respondents can return to an earlier question, review their answer, and change it before submitting. | 3.3.4 | | Not relying on colour alone | Instructions are written in plain language, and error messages carry both a visual cue and a text cue. | 1.4.1 | *** ## 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: | Platform | What the embedded player hides | | - | - | | YouTube | The whole control bar — so no captions button, and no visible play or pause control | | Vimeo | The captions button and the transcript panel | | Loom | The share button, the top bar, and the title. Playback controls, including captions, stay reachable | 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, the `lang` URL parameter sends a respondent straight to the correct language, so they do not need to use the switcher. See [Multi-language Surveys](https://formbricks.com/docs/surveys/general-features/multi-language-surveys.md). ### 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. Either way the card headings always sit under a top-level heading, but on a website or in-app survey that heading does not name the survey being answered. Before 6.1, a website or in-app survey has the card headings only, with no top-level heading above them. **Workaround for versions before 5.4, and for website and in-app surveys:** Keeping surveys short and putting one question on each screen reduces the amount of navigation a respondent has to do. Repeating the survey's purpose in the first question's headline gives a respondent the context that a heading naming the survey would otherwise carry. ### 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 a `lang` 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 `` 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 ### Assistive Technology We have **not** formally tested the survey UI against specific named combinations of assistive technology and browser — for example a particular screen reader paired with a particular browser version. We do not claim support for combinations we have not evidenced. If you use a specific assistive technology and hit a barrier in a Formbricks survey, we want to hear about it. See [Contact](#contact) below. *** ## Requesting This Documentation in Another Format This page and the full accessibility report are available in alternate formats on request, at no charge. If the format here does not work for you, tell us which format you need and we will provide it. See [Contact](#contact) below. *** ## Contact For accessibility questions about Formbricks, to request the full accessibility report, to ask for this documentation in another format, or to report an accessibility barrier in the survey UI, reach us in [GitHub Discussions](https://github.com/formbricks/formbricks/discussions). If you are a **survey respondent** and you cannot complete a survey that someone has sent you, contact the organisation that sent you the survey — they own the survey content and can offer you another way to respond. You are also welcome to raise it with us so we can fix the underlying barrier. *** ## Guidance for Survey Creators Formbricks handles the parts of accessibility that belong to the survey UI. The content you put into a survey is yours, and it decides whether the finished survey is usable. The following practices make a measurable difference. **Write question headlines that stand on their own.** A respondent using a screen reader may hear the headline without the surrounding context. "How satisfied were you with the onboarding call?" works; "And this one?" does not. **Describe every image that carries information.** Select the **Alt** button on a question image, an ending card image, or each Picture Selection option, and translate the text like the headline. Say what the image shows that matters for the answer — "Bar chart: sign-ups doubled from May to June", not "chart.png". Leave the field empty only for an image that is pure decoration. Before 6.1, put that information in the headline or the description instead. See [Image Text Alternatives](#image-text-alternatives) above. **Do not convey meaning with colour alone.** If a rating scale, an option, or an instruction depends on a respondent seeing red versus green, add a label, a number, or a word that carries the same meaning. **Caption your videos on the hosting platform, and summarise them as text.** See [Embedded Third-Party Video](#embedded-third-party-video) above. **Set the survey language correctly.** Choose the right default language and add translations for every language you send the survey in, so that assistive technology pronounces the content correctly. See [Multi-language Surveys](https://formbricks.com/docs/surveys/general-features/multi-language-surveys.md). **Leave the Back button enabled.** It is on by default, and it is what allows a respondent to review and correct an answer before submitting. Turn it off only when the survey design genuinely requires it — for example a quiz where going back would let a respondent change an answer after seeing the result. See [Hide Back Button](https://formbricks.com/docs/surveys/general-features/hide-back-button.md). **Keep questions short and ask one thing at a time.** This helps every respondent, and it particularly helps people using screen readers, screen magnification, or switch access, who move through content more slowly. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.