International Edition (VPAT® 2.5 INT) · October 2026
Based on WCAG 2.2 · Section 508 · EN 301 549
| Product Name | FormAssembly |
| Product Version | 1.0 |
| Report Date | October 2026 |
| Vendor | FormAssembly, Inc. |
| Contact | support@formassembly.com |
This report was produced using a combination of:
Evaluation covered the full authenticated application scope: homepage, login, onboarding, workflow builder, workflow list, form builder, connector settings, account settings, team settings, and legal pages.
| Standard | Version |
|---|---|
| Web Content Accessibility Guidelines (WCAG) | 2.2, Levels A and AA |
| Revised Section 508 standards (US) | Published January 18, 2017 |
| EN 301 549 Accessibility requirements for ICT products and services | V3.2.1 (2021-03) |
| Term | Definition |
|---|---|
| Supports | The product fully meets the criterion |
| Partially Supports | Some functionality meets the criterion; known gaps exist |
| Does Not Support | The product does not meet the criterion |
| Not Applicable | The criterion does not apply to this product |
| Not Evaluated | This criterion was not evaluated |
FormAssembly embeds the Fai AI agent — a chat panel provided by FormAssembly, Inc.'s core platform. All content and functionality in FormAssembly, including this embedded component, conforms as described below.
The e-signature signing page shows the document in Apryse WebViewer, a third-party viewer. Its text is exposed to screen readers through the viewer's reading-order mode, and each field the signer completes is named. The signature is captured in the viewer's own dialog, which offers typing and upload as well as drawing. A signature an earlier signer added is part of the document image and has no text alternative.
Overlay and menu components (Select, Dropdown, Context Menu, Command Menu, Dialog, Popover, Tooltip, Hover Card) manage focus correctly when open; the remaining automated-tool flags are minor and do not affect users.
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content | Supports | All images have descriptive alt attributes. Decorative images use alt="". Icons use aria-hidden="true". |
| 1.2.1 Audio-only and Video-only (Prerecorded) | Not Applicable | The product contains no audio-only or video-only content. |
| 1.2.2 Captions (Prerecorded) | Not Applicable | The product contains no prerecorded synchronized media. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) | Not Applicable | The product contains no prerecorded video content. |
| 1.3.1 Info and Relationships | Supports | Semantic HTML and ARIA landmarks are used throughout. Form inputs have associated labels. Navigation groups expose their name on the list the links belong to, so the grouping is conveyed to assistive technology and not by visual heading text alone. |
| 1.3.2 Meaningful Sequence | Supports | DOM order reflects visual reading order throughout the application. |
| 1.3.3 Sensory Characteristics | Supports | Instructions do not rely solely on shape, color, size, or spatial location. |
| 1.4.1 Use of Color | Supports | Color is never the sole means of conveying information. Status badges use both color and text labels. Error states use icons and text in addition to color. |
| 1.4.2 Audio Control | Not Applicable | The product contains no auto-playing audio. |
| 2.1.1 Keyboard | Supports | All functionality is operable via keyboard. Interactive elements receive focus in logical order. Custom components implement keyboard interaction patterns per ARIA Authoring Practices. |
| 2.1.2 No Keyboard Trap | Supports | Modal dialogs trap focus while open and return focus to the trigger element on close. No other keyboard traps exist. |
| 2.1.4 Character Key Shortcuts | Not Applicable | The product does not implement single-character keyboard shortcuts. |
| 2.2.1 Timing Adjustable | Not Applicable | The product has no time limits on user sessions or tasks. |
| 2.2.2 Pause, Stop, Hide | Not Applicable | The product contains no auto-updating content or moving content that starts automatically. |
| 2.3.1 Three Flashes or Below Threshold | Supports | The product contains no flashing content. |
| 2.4.1 Bypass Blocks | Supports | ARIA landmarks (main, nav, region) allow assistive technology users to bypass repeated content. |
| 2.4.2 Page Titled | Supports | All pages have a descriptive title element. |
| 2.4.3 Focus Order | Supports | Focus order follows a logical, meaningful sequence throughout all pages and modal dialogs. |
| 2.4.4 Link Purpose (In Context) | Supports | Links have descriptive text or aria-label attributes. Icon-only buttons have aria-label. |
| 2.5.1 Pointer Gestures | Supports | No multi-point or path-based gestures are required. Drag operations have keyboard-accessible alternatives. On the e-signature signing page, drawing a signature is optional: a signer can type or upload it instead. |
| 2.5.2 Pointer Cancellation | Supports | Click events fire on pointer up. No destructive actions are triggered on pointer down alone. |
| 2.5.3 Label in Name | Supports | Visible labels match or are contained within the accessible name for all interactive controls. |
| 2.5.4 Motion Actuation | Not Applicable | The product does not use device motion for any functionality. |
| 3.1.1 Language of Page | Supports | The lang attribute is set to "en" on all pages. |
| 3.2.1 On Focus | Supports | No context changes occur when an element receives focus. |
| 3.2.2 On Input | Supports | No context changes occur automatically on input. Form submissions require explicit action. |
| 3.3.1 Error Identification | Supports | Form validation errors are identified in text and linked to the relevant input via aria-describedby. For grouped controls (radio and checkbox sets, star ratings) the invalid state is placed on the group rather than on each option, so assistive technology is pointed at the question rather than at one arbitrary choice. |
| 3.3.2 Labels or Instructions | Supports | All form inputs have visible labels. Required fields are marked with both an asterisk and aria-required. |
| 4.1.2 Name, Role, Value | Supports | All custom interactive components expose appropriate name, role, and state via ARIA. |
| 4.1.3 Status Messages | Supports | Status messages use ARIA live regions (aria-live="polite" or role="alert") and do not require focus to be announced by screen readers. |
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) | Not Applicable | The product contains no live audio or video content. |
| 1.2.5 Audio Description (Prerecorded) | Not Applicable | The product contains no prerecorded video content. |
| 1.3.4 Orientation | Supports | The product does not restrict display to a single orientation. |
| 1.3.5 Identify Input Purpose | Supports | Autocomplete attributes are applied to all personal data fields as appropriate. |
| 1.4.3 Contrast (Minimum) | Supports | All text in FormAssembly meets the 4.5:1 minimum contrast ratio. |
| 1.4.4 Resize Text | Supports | Text can be resized up to 200% via browser zoom without loss of content or functionality. |
| 1.4.5 Images of Text | Supports | The product uses real text throughout. No images of text are used. |
| 1.4.10 Reflow | Supports | Content reflows at 320px viewport width without horizontal scrolling or loss of functionality. |
| 1.4.11 Non-text Contrast | Supports | Interactive controls, states, and focus indicators meet the 3:1 non-text contrast requirement; form fields are also identified by persistent labels. |
| 1.4.12 Text Spacing | Supports | Content and functionality are preserved when text spacing is adjusted per the criterion's requirements. |
| 1.4.13 Content on Hover or Focus | Supports | Tooltip and popover content triggered by hover or focus is persistent, hoverable, and dismissible. |
| 2.4.5 Multiple Ways | Supports | Pages are reachable via navigation menu and direct URL access. |
| 2.4.6 Headings and Labels | Supports | Headings are descriptive and reflect page/section content. Form labels clearly describe each input. |
| 2.4.7 Focus Visible | Supports | All interactive elements display a visible focus indicator meeting 3:1 contrast against adjacent colors. Focus moved programmatically — for example to the first invalid field after a failed submit — requests the visible indicator explicitly, so it is drawn even when the submit was activated by pointer. |
| 3.1.2 Language of Parts | Supports | The lang attribute is set appropriately on the root element. A respondent form declares the language it is rendered in, and each option of its language switcher declares its own language so assistive technology pronounces it correctly. User-generated form content may be in any language. |
| 3.2.3 Consistent Navigation | Supports | Navigation appears in the same location and order across all authenticated pages. |
| 3.2.4 Consistent Identification | Supports | Components with the same function are identified consistently across pages. |
| 3.3.3 Error Suggestion | Supports | Validation error messages describe how to correct the issue in plain language. |
| 3.3.4 Error Prevention (Legal, Financial, Data) | Supports | Destructive actions require explicit confirmation via a confirmation dialog before being processed. |
| 2.4.11 Focus Appearance | Supports | All focusable elements display a visible focus indicator. The focus ring uses a 2px solid outline with at least 3:1 contrast against adjacent colors, meeting the minimum area and contrast requirements of this criterion. |
| 2.5.7 Dragging Movements | Supports | Every drag operation in the product provides a single-pointer, non-drag alternative. The chat panel resize handle accepts keyboard input (Left/Right arrows to step, Home/End for min/max width). The repositionable onboarding checklist provides a move button that relocates it between screen corners with a single activation and announces the new position to assistive technology. |
| 2.5.8 Target Size (Minimum) | Supports | All interactive targets meet the 24×24 CSS pixel minimum. |
| 3.2.6 Consistent Help | Supports | Help mechanisms (documentation, accessibility contact email) appear in the same location across pages — in the site footer on all public-facing pages. |
| 3.3.7 Redundant Entry | Not Applicable | The product contains no multi-step processes requiring users to enter the same information more than once. |
| 3.3.8 Accessible Authentication (Minimum) | Supports | Authentication uses email and password entry. No cognitive function tests, CAPTCHAs, puzzles, or text transcription are required to authenticate. |
The Revised Section 508 standards incorporate WCAG 2.0 Level A and AA by reference. FormAssembly's conformance with WCAG 2.2 Level AA (documented above) subsumes all applicable WCAG 2.0 requirements.
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 302.1 Without Vision | Supports | The product is fully operable via screen reader. All content and state information is programmatically exposed. |
| 302.2 With Limited Vision | Supports | Text resizes to 200% without loss of content. Contrast ratios meet WCAG AA minimums. |
| 302.3 Without Perception of Color | Supports | Color is never the sole means of conveying information. |
| 302.4 Without Hearing | Not Applicable | The product contains no audio content. |
| 302.5 Without Speech | Not Applicable | The product does not require speech input. |
| 302.6 With Limited Manipulation | Supports | All functionality is keyboard accessible. No fine motor precision is required. |
| 302.7 With Limited Reach and Strength | Supports | No simultaneous actions are required. All targets meet minimum size requirements. |
| 302.8 Without Physical Access | Supports | The product is fully operable via keyboard and assistive technologies. |
| 302.9 With Limited Language, Cognitive, and Learning Abilities | Supports | Error messages are written in plain language. The interface uses consistent patterns and clear labels. |
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 501.1 Scope | Supports | Covered by WCAG 2.1 conformance documented above. |
| 504.2 Content Creation or Editing | Supports | The workflow builder and form editor controls are keyboard operable and labeled. |
| 504.2.1 Authoring Tools | Supports | The product enables creation of accessible workflows and forms. |
| 504.2.2 Authoring Tools for Accessible Content | Partially Supports | Authors can configure form labels and descriptions. Accessibility of respondent-facing form rendering depends on form configuration by the author. |
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 602.2 Accessibility and Compatibility Features | Supports | Accessibility features are documented in product documentation. |
| 602.3 Electronic Support Documentation | Supports | Support documentation is provided in accessible HTML format. |
| 603.2 Information on Accessibility and Compatibility Features | Supports | Accessibility contact information is provided at support@formassembly.com. |
| 603.3 Accommodation of Communication Needs | Supports | Support is available via email and text-based channels accessible to users with disabilities. |
EN 301 549 V3.2.1 references WCAG 2.1 AA for web content (clause 9); WCAG 2.2 is a backwards-compatible superset of WCAG 2.1. FormAssembly's conformance with WCAG 2.2 Level AA (documented above) satisfies all applicable web content requirements of EN 301 549.
All applicable criteria from EN 301 549 Chapter 9 map directly to WCAG 2.1 Success Criteria. See the WCAG 2.1 tables above for detailed conformance information.
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 10.0 | Not Applicable | FormAssembly does not distribute non-web documents as part of the product. |
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 11.8.2 Accessible Content Creation | Partially Supports | The product enables authors to create accessible data collection workflows. Accessibility of respondent-facing output depends on form configuration. |
| Criterion | Conformance Level | Remarks and Explanations |
|---|---|---|
| 12.1.2 Accessible Documentation | Supports | Product documentation is provided in accessible web format. |
| 12.2.2 Information on Accessibility and Compatibility Features | Supports | Accessibility features are documented and a dedicated contact is available. |
| 12.2.3 Effective Communication | Supports | Support is available via accessible text-based channels. |
| 12.2.4 Accessibility Services | Supports | Users with disabilities can contact support@formassembly.com for accommodation requests. |
This document is provided for informational purposes only. The information provided is accurate as of the report date and is subject to change. FormAssembly, Inc. makes no warranties, express or implied, regarding the accuracy of this document. This report does not constitute a legal certification of accessibility conformance.
VPAT® is a registered trademark of the Information Technology Industry Council (ITI). This report was prepared using the VPAT 2.5 INT template.
For accessibility support or to report an issue, contact accessibility@formassembly.com.