18 KiB

Raw Blame History

Voluntary Product Accessibility Template (VPAT®) 2.4

Product: DocuSeal — Open Source Document Signing Platform Product Version: 1.x (a11y-enhancements branch) Report Date: 2026-02-26 Report Version: 1.0 Contact: DocuSeal Accessibility Team Notes: This report covers the a11y-enhancements branch which introduces comprehensive WCAG 2.1 Level AA remediation across the full product. It supersedes the prior state of the master branch, which had numerous Level A violations. Evaluation was performed through manual code review, keyboard-only navigation testing, and static analysis.

Applicable Standards / Guidelines

This report covers conformance with the following accessibility standard:

Standard	Included
Web Content Accessibility Guidelines 2.1 (ISO/IEC 40500)	Yes
Revised Section 508 standards published January 18, 2017 and corrected January 22, 2018	Referenced
EN 301 549 Accessibility requirements for ICT products and services, V3.2.1 (2021-03)	Referenced

Terms

The following terms are used throughout this report to describe conformance:

Term	Meaning
Supports	The functionality meets the criterion without known defects.
Partially Supports	Some functionality 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 this product.
Not Evaluated	The product has not been evaluated against this criterion. This can only be used in WCAG Level AAA criteria.

Scope

This evaluation covers the following product surfaces:

Document Template Builder — web-based WYSIWYG interface for placing and configuring form fields on PDF pages (template_builder/ Vue application)
Document Signing Form — step-by-step form completion and e-signature flow (submission_form/ Vue application)
Dashboard — template and submission management views
Settings pages — account, API, email SMTP, e-sign certificate, and user profile settings
Shared UI components — navigation, search, flash messages, modals, drawers, pagination, file upload

Out of scope for this evaluation:

Third-party embedded widgets (React/Vue/Angular npm packages)
API endpoints (non-visual)
Administrative console interface (console.* subdomain in multitenant mode)

WCAG 2.1 Report

Table 1: Success Criteria, Level A

Criteria	Conformance Level	Remarks and Explanations
1.1.1 Non-text Content	Supports	All meaningful images have descriptive `alt` text. Page preview images in the template builder and submission viewer include `alt="Page N of M"`. Signature/initials canvas elements have `aria-label`. Decorative icons use `aria-hidden="true"`. PDF pages also expose extracted text content via a screen-reader-only region and a user-selectable Text View tab.
1.2.1 Audio-only and Video-only (Prerecorded)	Not Applicable	The product does not include prerecorded audio-only or video-only content.
1.2.2 Captions (Prerecorded)	Not Applicable	The product does not include prerecorded synchronized media.
1.2.3 Audio Description or Media Alternative (Prerecorded)	Not Applicable	The product does not include prerecorded video content.
1.3.1 Info and Relationships	Supports	Form controls have programmatically associated labels via `<label for>` or `aria-label`. Data tables include `<caption class="sr-only">` and `scope="col"` on column headers. Radio button groups are wrapped in `<fieldset>/<legend>`. Navigation regions use semantic `<nav aria-label>`. Headings establish logical document hierarchy.
1.3.2 Meaningful Sequence	Supports	Content is presented in a logical reading order in the DOM. Visual positioning achieved with CSS does not reorder the DOM sequence.
1.3.3 Sensory Characteristics	Supports	Instructions do not rely solely on shape, color, size, or spatial location. Field types are identified by name and icon label. Active navigation states use both color and `aria-current="page"`.
1.4.1 Use of Color	Supports	Color is not the sole means of conveying information. Active pagination pages use `aria-current="page"`. Toggle buttons use `aria-pressed`. Required fields are marked with both an asterisk and `required` attribute.
1.4.2 Audio Control	Not Applicable	The product does not play audio automatically.
2.1.1 Keyboard	Supports	All functionality is operable via keyboard. The drag-and-drop template builder includes keyboard-accessible alternatives: default field items in the field list accept Enter/Space to place a field; field type buttons detect keyboard activation and insert fields without requiring a drag gesture. Context menus on placed field areas are triggerable via ContextMenu key or Shift+F10. Settings dropdowns open on keyboard focus and close on Escape. The signing form step navigation, signature drawing, and all form controls are keyboard accessible. File upload areas expose a keyboard-accessible `<input type="file">`.
2.1.2 No Keyboard Trap	Supports	Modal dialogs implement a focus trap that keeps focus within the dialog. The Tab and Shift+Tab cycle within the open modal. Focus is returned to the triggering element on close. Drawers and dropdowns close on Escape without trapping focus.
2.1.4 Character Key Shortcuts	Not Applicable	The product does not implement single-character keyboard shortcuts that could conflict with AT.
2.2.1 Timing Adjustable	Not Applicable	The product does not impose time limits on user tasks.
2.2.2 Pause, Stop, Hide	Not Applicable	The product does not use moving, blinking, scrolling, or auto-updating content that is not user-initiated.
2.3.1 Three Flashes or Below Threshold	Supports	The product does not contain content that flashes more than three times per second.
2.4.1 Bypass Blocks	Supports	A skip navigation link is provided on both the main application layout and the public signing form layout, allowing keyboard users to bypass repeated navigation and jump directly to main content.
2.4.2 Page Titled	Supports	All pages have descriptive `<title>` elements that identify the current page and product name.
2.4.3 Focus Order	Supports	Focusable components receive focus in a sequence that preserves meaning and operability. Modal dialogs move focus to the first focusable element on open. After step transitions in the signing form, focus is managed to the relevant content area.
2.4.4 Link Purpose (In Context)	Supports	Links and buttons have descriptive labels accessible to assistive technology. Icon-only buttons include `aria-label`. Navigation links are self-describing. Folder card links include `aria-label` with the folder name.
2.5.1 Pointer Gestures	Supports	Operations that require dragging (template builder field placement) have single-pointer keyboard alternatives. The file upload drag-and-drop zone exposes a keyboard-accessible file input.
2.5.2 Pointer Cancellation	Supports	Click-based actions activate on the up-event (mouseup/pointerup), allowing users to cancel by moving the pointer off before releasing.
2.5.3 Label in Name	Supports	Visible text labels of interactive controls are included in or matched by their accessible names.
2.5.4 Motion Actuation	Not Applicable	The product does not use device motion or user motion as the sole input mechanism.
3.1.1 Language of Page	Supports	The `<html lang>` attribute is set to the active locale on all pages.
3.2.1 On Focus	Supports	Receiving focus does not trigger unexpected context changes.
3.2.2 On Input	Supports	Changing form control values does not trigger unexpected context changes without prior notice.
3.3.1 Error Identification	Supports	Input errors are identified and described to the user. Form validation errors use `role="alert"` live regions that announce to screen readers without moving visual focus. Error messages include a text description of the problem. Signature and initials errors are linked to the canvas via `aria-errormessage` and `aria-invalid`.
3.3.2 Labels or Instructions	Supports	All form controls have labels or instructions. Required fields are marked. Date format instructions are provided where applicable.
4.1.1 Parsing	Supports	HTML output does not contain duplicate `id` attributes on focusable elements. Markup is well-formed. ARIA usage follows the ARIA specification for allowed roles and properties.
4.1.2 Name, Role, Value	Supports	All user interface components have appropriate name, role, and value exposed to assistive technology. Custom interactive elements (DaisyUI collapsibles, dropdown triggers, progress dots, toggle view buttons) expose correct ARIA states (`aria-expanded`, `aria-pressed`, `aria-current`, `aria-selected`). `<a href="#">` elements acting as buttons have been converted to `<button type="button">`.

Table 2: Success Criteria, Level AA

Criteria	Conformance Level	Remarks and Explanations
1.2.4 Captions (Live)	Not Applicable	The product does not include live synchronized media.
1.2.5 Audio Description (Prerecorded)	Not Applicable	The product does not include prerecorded video content.
1.3.4 Orientation	Supports	Content is not restricted to a single display orientation. The signing form and template builder function in both portrait and landscape orientations.
1.3.5 Identify Input Purpose	Partially Supports	Standard user data fields (name, email, phone) in user profile and account settings include `autocomplete` attributes. Form fields in document templates are user-defined and vary by document; autocomplete attributes for arbitrary template fields are not provided.
1.4.3 Contrast (Minimum)	Partially Supports	Text contrast has been improved across the product: placeholder text colors updated from gray-300/400 to gray-600 (meeting 4.5:1 minimum), white-label text corrected. The DaisyUI default theme is used for most UI chrome; some DaisyUI theme colors (badge backgrounds, subtle backgrounds) have not been individually audited against all possible custom themes. Users who configure custom themes are responsible for ensuring contrast in their deployments.
1.4.4 Resize Text	Supports	The viewport meta tag no longer disables user zoom (`user-scalable=no` has been removed). Text can be resized up to 200% using browser zoom without loss of content or functionality.
1.4.5 Images of Text	Partially Supports	PDF documents are rendered as images for visual fidelity. A "Text View" tab is provided in both the template builder and the signing form viewer, presenting the same content as formatted HTML (when text extraction is available). Scanned/image-only PDFs do not have extracted text and rely solely on the image rendering.
1.4.10 Reflow	Supports	The application is responsive and content reflows at narrow viewports (320px CSS width) without horizontal scrolling for most views. The template builder PDF canvas is inherently two-dimensional and requires horizontal scrolling at small viewports, which is an essential exception.
1.4.11 Non-text Contrast	Partially Supports	Interactive component boundaries (input borders, button outlines, focus rings) have been improved. Focus ring styles (`focus:ring-2`) are applied to previously deficient inputs. Some DaisyUI default component borders (e.g., subtle card borders) may not reach 3:1 against adjacent backgrounds in all themes and have not been fully audited.
1.4.12 Text Spacing	Supports	No CSS declarations use `!important` to override letter-spacing, word-spacing, line-height, or spacing following paragraphs. Content remains readable when these properties are adjusted by user stylesheets.
1.4.13 Content on Hover or Focus	Supports	Tooltip and dropdown content triggered by hover or focus: (1) remains visible while the pointer hovers over it, (2) can be dismissed with Escape without moving focus, and (3) does not disappear when the pointer moves to the triggered content.
2.4.5 Multiple Ways	Supports	Users can reach content through navigation menus, search (on template/submission lists), breadcrumb trails (on folder views), and direct URL access.
2.4.6 Headings and Labels	Supports	Pages use a logical heading hierarchy. Form labels describe the purpose of the corresponding input. Settings sections use heading markup.
2.4.7 Focus Visible	Supports	All focusable elements display a visible focus indicator. Previously removed focus rings (`outline-none focus:ring-0`) have been replaced with `focus:ring-2` variants across the product.
2.5.3 Label in Name	Supports	(Repeated from Level A for completeness.) Visible labels match or are contained within accessible names.
3.1.2 Language of Parts	Partially Supports	The UI language is set via the `lang` attribute on `<html>`. User-supplied document content (PDF text, field values) may be in a different language than the UI and does not have per-element `lang` markup. The Text View panel includes `dir="auto"` on paragraph elements to handle right-to-left text direction automatically.
3.2.3 Consistent Navigation	Supports	Navigation mechanisms (top navbar, settings sidebar, breadcrumbs) appear in the same relative order across pages.
3.2.4 Consistent Identification	Supports	Components that have the same functionality are identified consistently throughout the product (e.g., the "Delete" action always uses the same icon and label).
3.3.3 Error Suggestion	Supports	When input errors are detected, suggestions for correction are provided where applicable. Signature validation errors describe what is required ("Signature is required"). Phone number validation errors describe the expected format.
3.3.4 Error Prevention (Legal, Financial, Binding)	Supports	Document submission (signing) requires explicit confirmation of intent. Users can review their input across all form steps before final submission. The decline document action is presented with a confirmation modal.
4.1.3 Status Messages	Supports	Status messages are conveyed to assistive technology without requiring focus. Success and error notifications use `aria-live` regions (`role="alert"` for errors, `aria-live="polite"` for status). Flash messages include `role="alert"` or `role="status"` with `aria-live` and `aria-atomic`. Template builder field add/remove operations announce via polite live regions. File operation success/error messages are announced via `announcePolite()` / `announceError()` utilities.

Known Limitations and Residual Risks

The following items are known to be partially addressed or deferred:

Scanned / image-only PDFs: PDFs without extractable text cannot provide a Text View. The page image alt text describes the page number only. A future OCR integration would address this gap.
Custom DaisyUI themes: Organizations deploying DocuSeal with custom Tailwind/DaisyUI themes are responsible for verifying color contrast ratios in their specific theme configuration.
Template builder — arrow-key nudging: While keyboard users can place fields (8-A), fine positioning via arrow-key nudging of placed field areas has not been implemented. Fields placed via keyboard land at a default position and must be repositioned via the settings inputs.
Country code combobox (phone step): The phone number entry uses a native <select> element for country code with aria-label="Country code". A custom combobox with search-by-country-name would provide a better experience but has not been implemented.
Autocomplete on template form fields: WCAG 1.3.5 autocomplete tokens apply to fields collecting personal information. Template-based form fields have user-defined names and may not map predictably to standard autocomplete token values.
1.4.5 Images of Text — scanned PDFs: The Text View tab is only shown when full text extraction succeeds for all documents in a submission. Submissions containing scanned PDFs do not display the Text View tab.

Evaluation Methods

This conformance report is based on the following evaluation methods:

Manual code review: All modified files were reviewed against WCAG 2.1 success criteria. ARIA usage was verified against the ARIA Authoring Practices Guide (APG).
Keyboard-only navigation: The full user workflow (login → template list → template builder → signing form → submission review) was traced for keyboard operability.
Static analysis: HTML structure, ARIA attribute correctness, and label associations were reviewed in source code.
Screen reader spot-checks: Selected interactions (modal focus, live region announcements, progress dots) were verified against expected AT behavior.

Automated testing using axe-core via RSpec (axe-core-rspec) infrastructure has been provisioned in spec/accessibility/ but a full automated sweep is recommended before claiming full AA conformance.

Legal Disclaimer

This document is provided for informational purposes and represents the best knowledge of the evaluation team at the time of publication. This is not a legal certification of accessibility conformance. Organizations requiring formal compliance assessment should engage an independent accessibility audit firm. The VPAT® format is a registered trademark of the Information Technology Industry Council (ITI).

VPAT® is a registered trademark of the Information Technology Industry Council (ITI). This template does not represent ITI's endorsement of the product.

18 KiB Raw Blame History