Accessibility

Signing Flows is built so that anyone can send, sign and check a document, whatever device or assistive technology they use. We aim at WCAG 2.2 level AA across the site, the signing pages and the console. This page says what is in place today, what we measured and what is still missing; it is not a certification, and no external audit has been done yet.

What is in place

• Motion. Decorative animation follows your system's reduced-motion setting, and you can turn it on or off for the whole site with the Animations switch at the bottom of every page. Your choice is remembered in this browser.
• Keyboard. On the signing page, the document scrolls with the keyboard, the field sheet keeps focus inside while it is open, and focus returns to where you were when it closes. Known gaps, tracked as defects: on a phone-width screen the keyboard cannot reach the wide tables in some blog articles (#2553), and in the console a button sits inside the expandable header of «Waiting on others» (#2554).
• Screen readers. The checker found no unlabelled controls on the pages it covered. The signing page announces its status once, and the flow builder announces each step when you move a person with the keyboard. The checker also reported text outside the named regions on the API page, tracked as a defect (#2555).
• Contrast. We measure contrast with an automated checker, and it is not yet met everywhere. The checker found text below the 4.5:1 ratio on six public pages (the home page, Connectors, the demo page, What's next, the user guide and the blog index); the large decorative numbers in the blog's series are far below it. These are tracked as defects (#2551, #2552). On the signing page the checker could not decide contrast, and nobody has checked it by hand yet.
• Touch targets. At phone width the checker found no control smaller than 24 pixels. At desktop width it found two in the console, the folder chevron (18 × 18 pixels) and the «Updated just now» line (16 pixels tall). Both are tracked as defects (#2558).

What we measured

On 1 November 2026 we ran an automated checker (axe-core 4.13.0, in Chromium, at 1280 and at 390 pixels wide) over the signing page, the public pages and the company console. The signing page showed no violations at either width. The checker also reported smaller notices that are not failures by themselves, such as skipped heading levels. It ran at 390 pixels wide, but it does not decide whether a page reflows or whether the focused element is visible. Automated checks decide only part of what WCAG asks.

What is missing

• No external audit has been done.
• Nobody has yet tested the site with a screen reader.
• The operator console and the Spanish and Portuguese texts were not measured.
• The contrast of what the checker could not decide has not been checked by hand.
• Whether the focused element is always visible has not been measured.
• Reflow down to a 390-pixel-wide screen has not been measured on its own.

If something blocks you

Tell us through the Contact link in the page footer and say which page and which assistive technology you were using. We treat an accessibility barrier as a defect.