Skip to content
FormFlow
Back to FormFlow

Accessibility Statement

Last updated:

This document is available in several languages. Where the translations differ, the English version governs.

Reading progress 0%
Language: English

FormFlow aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at level AA. This page says where we are today, what we have checked, what we know falls short, and how to tell us about a barrier.

1. Conformance status

FormFlow partially conforms to WCAG 2.2 level AA. “Partially conforms” means that some of our pages meet the standard, and some parts do not yet or have not been checked against it.

We have not had FormFlow audited against WCAG 2.2 by an independent party. This statement rests on our own testing, described below.

2. What this statement covers

  • The FormFlow website: the landing page and the legal pages (Terms, Privacy, Refunds, Changelog and this statement).
  • Sign-in, the customer panel where you build forms and read submissions, and the staff panel.
  • Hosted form pages, which FormFlow serves for a form, and Microsites, which are pages built in FormFlow.

Two things are outside it. A form embedded on your own website is drawn inside your page, so how accessible it is also depends on that page. We write the form’s own markup and styles to follow the visitor’s system settings for reduced motion, more contrast and forced colours, but we do not control the page around it. And content written by our customers, such as form labels, Microsite text and images, is theirs; FormFlow provides the tools but cannot vouch for it.

3. How we check

  • Automated scans. Our tests load real pages in a browser and run an automated accessibility scan (axe) that must report no serious issues. Today that covers the landing page in English and Arabic, the Terms page in English and Arabic, the Changelog and this statement, the customer sign-in page, the first screen of the customer panel and of the staff panel, the API reference, every Microsite theme and starter page, Hosted forms (one of them with a grid question), and a few more customer-panel screens. Several of these are also scanned with the Display preferences panel open.
  • Contrast. The colour pairs in our Microsite palettes and form Styles are checked against the AA contrast ratios by tests, and some panel text colours are measured in a browser.
  • Keyboard. Tests walk a branching Hosted form, Microsite scroll regions, an image lightbox and a panel dialog with the keyboard alone, and check that the floating Save bar never hides the control that has focus.
  • Languages and direction. FormFlow is available in nine languages, two of them written right to left (Arabic and Urdu). Tests check the mirrored layout and the script faces on the website and the panels.
  • Motion and contrast settings. The landing page, Hosted pages, Microsites, the customer panel and the styles of embedded forms respond to the visitor’s system setting for reduced motion. Those, and also the legal pages, the sign-in pages and the staff panel, respond to the system setting for more contrast. Embedded forms and the landing page also adapt to forced colours. We have not tested every screen in these modes.

Automated tools find only part of the problems, and a clean scan does not mean a page has no barriers. Our testing with assistive technologies, such as screen readers, is limited.

4. Known limitations

  • Not every screen is scanned. Beyond the first screen of each panel, most customer-panel and staff-panel screens and most Hosted form pages are covered by few automated accessibility scans or none, so barriers may exist there that we have not found.
  • In right-to-left languages, the file upload control in the customer panel stays left to right, because the component we use has no right-to-left mode.
  • The theme switcher (light, dark or system) that comes with the framework the panels are built on, and appears on the sign-in pages and in the panels, fails an automated accessibility check: its options are not placed inside the container that assistive technology expects (axe rule aria-required-parent). We scan those pages with it removed, and have not yet replaced it.
  • Apart from English, the eight other languages were drafted by machine and have not been reviewed by a native speaker. Wording may be unclear or wrong, which can itself be a barrier.
  • Error pages and the API reference, which a third-party documentation tool renders, do not offer Display preferences. We scan the API reference, but we cannot change how that tool is built.
  • Our Microsite palettes and form Styles are tested for contrast, but colours a Team chooses outside them, and the images and text a Team adds, cannot be promised to meet the standard.

5. Display preferences

Most of our pages offer Display preferences: larger text, high contrast, reduced motion, highlighted links and focus, and readable spacing. They are a convenience for the reader. They are not how we meet the standard, and we do not count them towards it; a page that fails WCAG is a defect we fix, not something a setting makes up for.

6. Report a barrier

If something on FormFlow is hard or impossible for you to use, email info@formflow.digital. Tell us the page address, what you were trying to do, and the browser, device and assistive technology you use if you know them. We will reply, and where the barrier is ours to fix, tell you what we plan to do.

This statement was prepared on 2026-10-16 from our own testing. We will update it as our testing and the product change.