ToWebForm Accessibility Conformance Report
WCAG Edition
(Based on VPAT Version 2.5Rev) ®
Name of Product/Version:
ToWebForm web application, release of November 1, 2026 (build 9d715fa)
Report Date:
November 2026
Product Description:
ToWebForm is a web application that turns PDF forms into mobile-friendly web forms. An organization uploads a PDF, reviews and edits the detected fields in a form builder or directly on the PDF, and publishes the form. Respondents fill in the form in a web browser, sign electronically, and download a copy of their answers. ToWebForm writes the answers back onto the original PDF for the organization.
ToWebForm also publishes read-only document pages, collects several forms as one packet, routes forms to multiple signers, translates forms and answers, and tracks contracts and renewal dates.
Contact Information:
Notes:
Scope: this report covers the ToWebForm web application at www.towebform.com. Remarks begin with the area they describe. Respondent pages: the pages respondents use to fill in, sign and download forms, packets and document pages, including the accessible copy of their answers. Dashboard: the signed-in application customer staff use to build, publish and manage forms, submissions and contracts. Website: the public website, help center, and sign-in and account pages.
Not covered: the internal ToWebForm staff administration area; third-party pages that ToWebForm sends people to (Stripe checkout and billing portal, Google and Microsoft sign-in); email messages; and the PDF files produced from submissions, which are filled copies of the customer's own PDF.
Customer content: form titles, field labels, help text, instructions, translations and document page text come from the customer's PDF and the customer's edits. Whether that content meets WCAG depends on the customer. ToWebForm provides tools to review and correct it (field label editing, Needs review flags and accessibility overrides). The ToWebForm Terms of Service describe this shared responsibility.
Alternate version: respondents can switch between the Web form view and the PDF view of a form on the same page. The Web form view is the conforming alternate version for criteria the PDF view cannot meet, such as 1.4.10 Reflow and 2.5.8 Target Size (Minimum).
Report history: this is the first ToWebForm Accessibility Conformance Report.
Evaluation Methods Used:
Testing was done in November 2026 by evaluators familiar with ToWebForm's product flows, on a build of the release named above, using Chromium on Windows. Methods:
Automated testing: axe-core 4.10 and 4.14 with the WCAG 2.0, 2.1 and 2.2 Level A and AA rules on each tested page, with the dashboard tested in both the light and dark themes, plus ToWebForm's automated accessibility test suites, which render every form field type and run axe-core on the result.
Keyboard testing: each flow was operated with Tab, Shift+Tab, Enter, Space, Escape and the arrow keys, recording the focused element and its focus indicator at each step.
Manual checks: reflow at 320 CSS pixels wide, text spacing overrides (WCAG 1.4.12), focus not obscured, target size, content on hover or focus, error identification and status messages. Two published forms (one with initials fields, one with signature and table fields) were tested in both the Web form view and the PDF view, through the review step, submission, the confirmation page and the accessible answers page. The submission detail page in the dashboard was tested with the resulting submission. The sign-in, sign-up, two-factor, password reset and email verification pages were tested while signed out, along with the dashboard dialogs, the Doris guide panel, and the Counter Card Designer and print pages. Smart Packets, signing links, forms translated into Arabic (right to left) and a published document page were also tested.
Code review: criteria that depend on behavior a browser pass does not show (timing, motion, keyboard shortcuts, pointer handling, authentication and language attributes).
Assistive technology: NVDA 2026.3 with Chromium on Windows, on a Smart Packet, a published web form through submission, a signing link and a published document page. JAWS, VoiceOver and TalkBack were not tested.
Applicable Standards/Guidelines
This report covers the degree of conformance for the following accessibility standard/guidelines:
| Standard/Guideline | Included In Report | |
|---|---|---|
| Web Content Accessibility Guidelines 2.0 | Level A (Yes) Level AA (Yes) Level AAA (No) | |
| Web Content Accessibility Guidelines 2.1 | Level A (Yes) Level AA (Yes) Level AAA (No) | |
| Web Content Accessibility Guidelines 2.2 | Level A (Yes) Level AA (Yes) Level AAA (No) |
Terms
The terms used in the Conformance Level information are defined as follows:
- Supports: The functionality of the product has at least one method that meets the criterion without known defects or meets with equivalent facilitation.
- Partially Supports: Some functionality of the product does not meet the criterion.
- Does Not Support: The majority of product functionality does not meet the criterion.
- Not Applicable: The criterion is not relevant to the product.
- Not Evaluated: The product has not been evaluated against the criterion. This can only be used in WCAG Level AAA criteria.
WCAG 2.x Report
Note: When reporting on conformance with the WCAG 2.x Success Criteria, they are scoped for full pages, complete processes, and accessibility-supported ways of using technology as documented in the WCAG 2.0 Conformance Requirements.
Table 1: Success Criteria, Level A
Notes: Remarks begin with the area they describe: Respondent pages, Dashboard or Website. See the Notes section above.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.1.1 Non-text Content (Level A) | Supports | Respondent pages: icons are hidden from assistive technology or have text alternatives, the signature drawing area has a text label, and the PDF view keeps a text layer behind each page image. Dashboard and Website: images and icon buttons have text alternatives. Images in customer PDFs are the customer's content. |
| 1.2.1 Audio-only and Video-only (Prerecorded) (Level A) | Not Applicable | All areas: the product contains no prerecorded audio-only or video-only content. |
| 1.2.2 Captions (Prerecorded) (Level A) | Not Applicable | All areas: the product contains no prerecorded video with audio. |
| 1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A) | Not Applicable | All areas: the product contains no prerecorded video. |
| 1.3.1 Info and Relationships (Level A) | Supports | Respondent pages: fields use programmatic labels, radio and checkbox groups use fieldset and legend, table fields use column headers with labels on each cell (also in the submission detail page, which shows the column names set in the form), and pages use headings and landmarks. Respondent pages: in file upload and image upload fields, the file input is a separate control next to the drop area button. Dashboard: the sample inputs shown inside field cards in the form builder are labeled, and the usage bars on the Billing page have accessible names. Controls in the Counter Card Designer have labels tied to them. |
| 1.3.2 Meaningful Sequence (Level A) | Supports | Respondent pages: the Web form view presents fields in a single column in the order set by the form author. The PDF view follows the Tab order index set for each field. Dashboard and Website: reading order matches the visual order. |
| 1.3.3 Sensory Characteristics (Level A) | Supports | All areas: instructions do not rely on shape, size, location or sound alone. Instructions written by customers are the customer's content. |
| 1.4.1 Use of Color (Level A) | Supports | All areas: errors use text and an icon as well as color, required fields are marked with an asterisk and explained in text, and links in body text are underlined. |
| 1.4.2 Audio Control (Level A) | Not Applicable | All areas: the product does not play audio automatically. |
| 2.1.1 Keyboard (Level A) | Supports | Respondent pages: every field type, the signature and initials dialog (Draw, Type and Upload tabs), the date picker, the table Add Row and Delete row buttons, the review step and the address suggestions can be operated with a keyboard. Dashboard: in the visual PDF editor, a selected field can be moved with the arrow keys, and its position and size can be typed in the field properties pane. Other dashboard functions can be operated with a keyboard. Website: on the sign-in, sign-up and password reset pages, the Show password button and the Back to towebform.com link can be reached and used with a keyboard. |
| 2.1.2 No Keyboard Trap (Level A) | Supports | Respondent pages and Website: no keyboard traps were found. Dialogs close with Escape and return focus to the control that opened them. Dashboard: no keyboard traps were found. In the visual PDF editor, editing keys act on the selected field only while focus is on the PDF pages, Escape clears the selection, and Tab moves on to the rest of the page after the last field. |
| 2.1.4 Character Key Shortcuts (Level A 2.1 and 2.2) | Supports | All areas: keyboard shortcuts use a modifier key (Ctrl or Cmd for undo and redo). Arrow, Delete and Backspace keys act only while a field is selected in the PDF editor; these are not character keys. |
| 2.2.1 Timing Adjustable (Level A) | Supports | Respondent pages: answers are saved as a draft while the respondent works, there is no time limit to fill a form, and signing links stay valid for days, which exceeds the 20 hour exception. Dashboard: there is no idle sign-out. Notifications stay for 5 seconds (10 seconds for errors), pause while hovered or focused, and can be dismissed. |
| 2.2.2 Pause, Stop, Hide (Level A) | Supports | All areas: the only moving content is loading indicators, which stop when loading finishes. Animations respect the reduced motion setting. |
| 2.3.1 Three Flashes or Below Threshold (Level A) | Supports | All areas: no content flashes more than three times per second. |
| 2.4.1 Bypass Blocks (Level A) | Supports | All areas: a Skip to main content link is the first focusable element on every page, and pages use header, navigation and main landmarks. Every page, including the sign-in, account and print pages, has a main region that the skip link moves to. |
| 2.4.2 Page Titled (Level A) | Supports | Respondent pages: titles use the form or document name. The accessible copy of a respondent's answers is titled "Your answers" followed by the form name, in the respondent's language. Website: marketing, help, legal, sign-in, sign-up, password reset and demo pages have descriptive titles, for example "Reset Password | ToWebForm". Dashboard: every page has a title that names the page, for example "Forms - Dashboard | ToWebForm", including the Counter Card Designer and its print page. |
| 2.4.3 Focus Order (Level A) | Supports | Respondent pages: focus order follows the form. After a failed submit, focus moves to the first field with an error, the review step moves focus to its heading, and dialogs move focus into themselves and back to the control that opened them. After Start over or Keep answers on a restored draft, focus moves to the form heading. In Smart Packets, moving to another step moves focus to that step's heading. Dashboard: in the visual PDF editor, selecting a field from the field list moves focus into its properties pane, and closing the pane returns focus to that field in the list. Dialogs move focus into themselves, keep Tab and Shift+Tab inside, and return focus to the control that opened them. Opening the Doris guide moves focus to its question box, and minimizing it returns focus to the Ask Doris button. Controls that change or disappear when used (Publish, Save, language toggles, and the steps and recipient rows in Send for signature) keep focus on the same control or move it to the next sensible place, and confirmation dialogs keep focus inside while their action runs. |
| 2.4.4 Link Purpose (In Context) (Level A) | Supports | All areas: link text, alone or with its surrounding heading or sentence, describes the destination. |
| 2.5.1 Pointer Gestures (Level A 2.1 and 2.2) | Supports | Respondent pages: drawing a signature is a path-based gesture, and the Type and Upload tabs in the signature dialog provide single-pointer alternatives. No other function needs a path-based or multipoint gesture. |
| 2.5.2 Pointer Cancellation (Level A 2.1 and 2.2) | Supports | All areas: actions run when the pointer is released. Drag operations in the dashboard can be cancelled with Escape. |
| 2.5.3 Label in Name (Level A 2.1 and 2.2) | Supports | All areas: accessible names of controls with visible text start with that text, for example the signature button "Tap or click to sign: Employee Signature", the PDF view signature box "Sign Here: Employee Signature", the phone country picker "+1, United States: change country" and the dashboard guide button "Ask Doris: open the product guide". The Help Center label sits outside the home link. Language toggles in the form languages panel are named, for example, "Enable: Spanish on this form". |
| 2.5.4 Motion Actuation (Level A 2.1 and 2.2) | Not Applicable | All areas: no function is operated by device motion or user motion. |
| 3.1.1 Language of Page (Level A) | Supports | All areas: the page language is set to English. Respondent pages: when a respondent selects another language, the form and document regions are marked with that language and with right-to-left direction where needed. |
| 3.2.1 On Focus (Level A) | Supports | All areas: moving focus to a control does not change the context. |
| 3.2.2 On Input (Level A) | Supports | All areas: changing a setting does not change the context unexpectedly. Choosing a language on a respondent page changes the language of the form and announces the change. |
| 3.2.6 Consistent Help (Level A 2.2 only) | Supports | Dashboard: the Help and Docs link and the Ask Doris help button appear in the same place on every page. Website: the Help link and support email appear in the same place on every page. Respondent pages: the form layout is the same on every form. |
| 3.3.1 Error Identification (Level A) | Supports | Respondent pages: on submit, a summary lists each error, focus moves to the first field with an error, each field is marked invalid and linked to its error text. Website and Dashboard: sign-in, sign-up and settings forms identify errors in text. |
| 3.3.2 Labels or Instructions (Level A) | Supports | Respondent pages: every field has a visible label and required fields are explained at the top of the form. Labels come from the customer's PDF and can be edited by the customer. Dashboard and Website: inputs have visible labels that are tied to them, including in the Counter Card Designer. |
| 3.3.7 Redundant Entry (Level A 2.2 only) | Supports | Respondent pages: answers are kept as a draft, packets fill fields that repeat across forms, and information already entered is not requested again in the same process. |
| 4.1.1 Parsing (Level A) WCAG 2.0 and 2.1 – Always answer ‘Supports’ WCAG 2.2 (obsolete and removed) - Does not apply | Supports | For WCAG 2.0 and 2.1, the September 2023 errata update indicates this criterion is always supported. See the WCAG 2.0 Editorial Errata and the WCAG 2.1 Editorial Errata. |
| 4.1.2 Name, Role, Value (Level A) | Supports | Respondent pages: fields, the signature dialog (dialog with labeled tabs), the date picker and the address suggestions (combobox) expose their names, roles and states. NVDA read the names, roles and states of the fields, the signature dialog, the Smart Packet step buttons and the document page links as shown on screen. Respondent pages: in file upload and image upload fields, the file input is a separate control next to the drop area button. Dashboard: the usage bars on the Billing page and the sample inputs inside form builder field cards have accessible names. Field boxes on the visual PDF editor canvas have no role or name; the same fields are reached and edited through the field list and the field properties pane. Controls in the Counter Card Designer have accessible names. |
Table 2: Success Criteria, Level AA
Notes: Remarks begin with the area they describe: Respondent pages, Dashboard or Website. See the Notes section above.
| Criteria | Conformance Level | Remarks and Explanations |
|---|---|---|
| 1.2.4 Captions (Live) (Level AA) | Not Applicable | All areas: the product contains no live audio. |
| 1.2.5 Audio Description (Prerecorded) (Level AA) | Not Applicable | All areas: the product contains no prerecorded video. |
| 1.3.4 Orientation (Level AA 2.1 and 2.2) | Supports | All areas: content is not locked to one orientation and works in portrait and landscape. |
| 1.3.5 Identify Input Purpose (Level AA 2.1 and 2.2) | Supports | Respondent pages: fields that collect the respondent's own name, address, phone, email and birth date get the matching autocomplete value based on their label; fields about other people (such as a spouse or emergency contact) do not. Website: sign-in and sign-up fields use email, current-password, new-password and one-time-code. |
| 1.4.3 Contrast (Minimum) (Level AA) | Supports | Respondent pages: text meets 4.5:1 (for example, input text and placeholders at 5.85:1 or more), including the e-signature consent error message (5.94:1), packet error banners and the "Sign Here" and "Initial Here" text in PDF view boxes (5.62:1). Website: text meets 4.5:1, including the Help Center header, error messages on the sign-up page and the System Requirements page. Dashboard: text meets 4.5:1, in both the light and dark themes, including error messages, destructive action buttons such as Delete submission, status badges, the Counter Card Designer and its print page, and the translation status text in the form languages panel. |
| 1.4.4 Resize text (Level AA) | Supports | All areas: text can be resized to 200% without loss of content or function. After a form is submitted, the confirmation screen stays in place when zooming or rotating the screen. Respondent pages: the Web form view is the conforming alternate version for the PDF view. |
| 1.4.5 Images of Text (Level AA) | Supports | Respondent pages: the PDF view shows page images of the customer's PDF, and the Web form view presents the same content as text. Other areas use text, except logos. |
| 1.4.10 Reflow (Level AA 2.1 and 2.2) | Supports | All areas: content reflows to a single column at 320 CSS pixels wide without horizontal scrolling, except data tables and the PDF view, which need two-dimensional layout. Wide table fields scroll inside their own box, so the rest of the page does not scroll sideways. The website header and contract pages, Smart Packets and document pages were also checked at 320 CSS pixels. Respondent pages: the Web form view is the conforming alternate version for the PDF view. |
| 1.4.11 Non-text Contrast (Level AA 2.1 and 2.2) | Supports | All areas: input borders (5.85:1 or more) and focus indicators (a 2 to 3 pixel blue outline or ring) meet 3:1 against adjacent colors. Respondent pages, PDF view: the boxes drawn over the PDF for each field have a solid blue border at 4.17:1 against the page. |
| 1.4.12 Text Spacing (Level AA 2.1 and 2.2) | Supports | All areas: with WCAG text spacing applied, no content or function was lost. In the form builder, the short summary on the Form settings button is truncated; the same information is shown in the settings panel. |
| 1.4.13 Content on Hover or Focus (Level AA 2.1 and 2.2) | Supports | Respondent pages and Website: no content appears only on hover or focus. Dashboard: the "More information" help tooltips and the storage usage card stay visible while the pointer is over them, can be dismissed with Escape without moving focus, and stay until the pointer and focus leave. |
| 2.4.5 Multiple Ways (Level AA) | Supports | Website: header and footer navigation, the help center with search, and a sitemap. Dashboard: sidebar navigation plus links from the overview. Respondent pages are steps in a process, which is an exception. |
| 2.4.6 Headings and Labels (Level AA) | Supports | All areas: headings and labels describe their topic or purpose. Field labels on respondent pages come from the customer's PDF; the form builder flags fields that need review so customers can correct them. The submission detail page heading names the form. Repeated controls name their item, for example "Edit: Employee Name" in the form languages panel and "Shown as: 1. Checking in" in the document page editor. |
| 2.4.7 Focus Visible (Level AA) | Supports | All areas: every focusable control shows a visible focus indicator (a 3 pixel blue outline with offset, or a 2 pixel ring on inputs). Items that a link or button moves focus to, such as blocks in the document page editor, show a solid ring while focused. |
| 2.4.11 Focus Not Obscured (Minimum) (Level AA 2.2 only) | Supports | Website and Dashboard: at narrow widths, where a navigation bar is fixed to the bottom of the screen, the page keeps scroll padding equal to the bar, so a control that receives keyboard focus scrolls clear of it. Respondent pages: no fixed bars cover focused controls. |
| 2.5.7 Dragging Movements (Level AA 2.2 only) | Supports | Respondent pages: no function requires dragging. Signatures can be typed or uploaded and files can be chosen by clicking. Dashboard: fields in the form builder can be reordered with the Move field up and Move field down buttons, and fields in the visual PDF editor can be placed and sized by typing X, Y, Width and Height values. Recipients in Send for signature can be reordered with Move up and Move down buttons. |
| 2.5.8 Target Size (Minimum) (Level AA 2.2 only) | Supports | All areas: controls are at least 24 by 24 CSS pixels or have enough spacing; form controls are 48 pixels tall. Respondent pages: fields in the PDF view follow the size of the PDF (table rows can be 21 pixels tall), and the Web form view on the same page is the conforming alternative. Website: the Show password button on the sign-in pages is 34 by 48 CSS pixels. |
| 3.1.2 Language of Parts (Level AA) | Supports | Respondent pages: translated forms, documents and answers are marked with their language, and English text inside a translated page is marked as English. Dashboard: language names written in their own language, in language settings and the form languages panel, are marked with that language. |
| 3.2.3 Consistent Navigation (Level AA) | Supports | Website and Dashboard: navigation appears in the same order on every page. |
| 3.2.4 Consistent Identification (Level AA) | Supports | All areas: controls with the same function have the same name and icon throughout. |
| 3.3.3 Error Suggestion (Level AA) | Supports | All areas: error messages say what is wrong and how to fix it (for example "Email is required"), and date fields show the expected format. |
| 3.3.4 Error Prevention (Legal, Financial, Data) (Level AA) | Supports | Respondent pages: forms with a signature or initials show a Review your answers step before submitting, and respondents must agree to electronic signature consent. Smart Packets end with a review step and are submitted only when the respondent presses Submit All Documents. Dashboard: deleting forms and other destructive actions ask for confirmation. |
| 3.3.8 Accessible Authentication (Minimum) (Level AA 2.2 only) | Supports | Website: sign-in supports password managers and pasting, has a Show password button, and offers email sign-in links and Google and Microsoft sign-in. Two-factor codes can be pasted or filled automatically. No cognitive function test is used. |
| 4.1.3 Status Messages (Level AA 2.1 and 2.2) | Supports | All areas: status messages use status and alert roles (upload progress, language changes, validation errors and notifications), and the Doris chat uses a log role. In the form builder, the whole preview area is a polite live region, which can make announcements longer than needed. |
Legal Disclaimer (ToWebForm)
This report describes ToWebForm as evaluated on the date shown and is provided for information. It is not a warranty or a certification of conformance, and ToWebForm may change the product after the report date. Customers are responsible for the accessibility of the content they upload or write and for verifying that their published forms meet the requirements that apply to them, as described in the Shared Responsibility section of the ToWebForm Terms of Service at www.towebform.com/terms.