Voluntary Product Accessibility Template® (VPAT®)

Product/Version

DocAccess (SaaS platform – cloud-based document viewer & transcription service)

Scope of Evaluation

This report covers the end‑user document viewer and the HTML transcripts it renders (including content reproduced from customer PDF documents), the customer application (sign‑in, password reset, account setup), the administrative dashboard used by customer staff, and the public docaccess.com website forms. Where a remark applies to one of these surfaces specifically, it names that surface.

Report Date

July 7 2025 · last revised August 7 2026 (see Revision History)

Revision History

July 30 2026 — completed the 1.3.1 remark; re‑evaluated 1.3.5, now Partially Supports with its exception stated; added the Scope of Evaluation row.

August 7 2026 — Evaluation Methods row updated: reviewers are cited only where written confirmation of testing or an organizational partnership is documented; reviewers who could not yet be documented are no longer individually named.

Contact Information

support@docaccess.com · Streamline Software, Inc.

Evaluation Methods Used

Combination of automated testing (axe‑core, WAVE, Lighthouse, Pa11y), manual code review, and assistive‑technology user testing. Independent usability audits are conducted periodically by accessibility consultants. Individual reviewers include Shawn Jordison (@theaccessibilityguy) and Carter Temm (IAAP‑certified Web Accessibility Specialist), each of whom has provided written confirmation of their testing, along with other consultants not individually named; organizational review is provided by Level Access, Inc. (formal periodic platform review, including live user testing across a wide range of disabilities and assistive technologies). Documented testing has included hands‑on screen‑reader evaluation and organized usability sessions with dozens of participants across a range of disabilities, on desktop (Windows, macOS) and mobile (iOS, Android) devices. Conformance claims are based on testing with current versions of JAWS, NVDA, VoiceOver (macOS/iOS), and TalkBack (Android), plus screen magnification, high‑contrast mode, and speech‑to‑text input (Dragon NaturallySpeaking), and keyboard‑only navigation on the latest versions of Chrome, Firefox, Safari, and Edge.

Real-time support is provided and fully subsidized by DocAccess to any user in need. Aira provides recordings, with the user’s permission, back to DocAccess to provide dynamic feedback capabilities and recorded/reproduced friction points, making it one of the most interactive expert-assisted feedback loops.

Applicable Standards/Guidelines

Web Content Accessibility Guidelines (WCAG) 2.1 levels A & AA

Revised Section 508 of the U.S. Rehabilitation Act (Jan 2018)

EN 301 549 v3.2.1 (2021‑03) – European Union accessibility requirements

1.1.1 Non‑text Content

A

Supports

All images in transcripts receive descriptive alt text. For scanned or complex images, AI‑generated alt text is reviewed by human auditors with live assistance from Aira. Decorative images are marked with empty alt strings.

1.2.1 Audio‑only & Video‑only (Prerecorded)

A

Not Applicable

DocAccess serves static document transcripts; no prerecorded audio‑only or video‑only content is provided by the platform itself.

1.2.2 Captions (Prerecorded)

A

Not Applicable

Same as above.

1.2.3 Audio Description or Media Alternative (Prerecorded)

A

Not Applicable

1.2.4 Captions (Live)

AA

Not Applicable

1.2.5 Audio Description (Prerecorded)

AA

Not Applicable

1.3.1 Info & Relationships

A

Supports

Transcripts are generated as semantic HTML — headings (h1–h6), lists, and tables marked up with <table>, <thead>, <th>, <tbody>, and <td> — so the structure and relationships conveyed visually in the source document are exposed to assistive technology. The viewer applies an additional render‑time pass that corrects table header scope attributes (col, row, colgroup, rowgroup) where the generated markup requires it.

1.3.2 Meaningful Sequence

A

Supports

Reading order is preserved through OCR zone sequencing; verified with screen‑reader walkthroughs.

1.3.3 Sensory Characteristics

A

Supports

Instructions do not rely solely on shape, color, size, or visual location.

1.3.4 Orientation

AA

Supports

Content reflows appropriately in both portrait and landscape orientations.

1.3.5 Identify Input Purpose

AA

Partially Supports

The platform’s own fields that collect information about the user identify their purpose programmatically via HTML autocomplete attributes — the document viewer’s optional email field on the accessible‑transcript request/notification form, the public website forms, and the sign‑in, password‑reset, and account‑setup forms (autocomplete="email", "username", "current-password", "new-password", "given-name", etc.). Exception: input fields reproduced inside HTML transcripts of customer PDF forms do not yet carry autocomplete attributes; remediation is planned in the transcription pipeline. Administrative dashboard fields collect document‑ and site‑configuration data rather than information about the user; admin screens are otherwise included in the evaluation scope where noted (see 2.2.1, 3.2.2, 3.3.1).

1.4.1 Use of Color

A

Supports

Color is never the sole means of conveying information in the viewer UI; redundant text or patterns are used.

1.4.2 Audio Control

A

Not Applicable

No audio plays automatically.

1.4.3 Contrast (Minimum)

AA

Supports

All text maintains a contrast ratio ≥ 4.5:1 against adjacent background; verified with Lighthouse and manual sampling.

1.4.4 Resize Text

AA

Supports

Text can be zoomed to 200 % via browser controls without loss of content or functionality.

1.4.5 Images of Text

AA

Supports

Platform does not produce images of text except when conveying essential scanned artifacts embedded in the PDF; in those cases full text OCR and alt text are provided.

1.4.10 Reflow

AA

Supports

Responsive CSS enables reflow at as little as 320 CSS px width with no two‑directional scrolling, with tables enabled to slide in viewport if needed.

1.4.11 Non‑text Contrast

AA

Supports

All active UI components (buttons, focus indicators, icons) meet 3:1 contrast ratio.

1.4.12 Text Spacing

AA

Supports

Content remains readable and functional when the user overrides spacing to the specified metrics.

1.4.13 Content on Hover or Focus

AA

Supports

Tooltips and pop‑overs can be dismissed, are hover‑persistent, and are keyboard‑accessible.

2.1.1 Keyboard

A

Supports

All functionality (search, outline navigation, language selector, Q&A, download) is operable via keyboard.

2.1.2 No Keyboard Trap

A

Supports

Focus can be moved into and away from all components; ESC closes dialogs.

2.1.4 Character Key Shortcuts

A

Not Applicable

No single‑key shortcuts are implemented. Other keyboard shortcuts are available and adapt to operating system (e.g. Keyboard Shortcuts for Mac OS, PC) as to not conflict with existing screenreader keyboard shortcuts.

2.2.1 Timing Adjustable

A

Supports

No time‑limited tasks for end users. Session timeouts for admin dashboard are configurable and provide warnings.

2.2.2 Pause, Stop, Hide

A

Not Applicable

There is no moving, blinking, scrolling, or auto‑updating content in the viewer.

2.3.1 Three Flashes or Below Threshold

A

Supports

No flashing content.

2.4.1 Bypass Blocks

A

Supports

“Skip to Transcript” link provided at top; landmarks enable AT users to jump directly to main content. Page Up/Page Down jump, and hotkeys allow viewport transition.

2.4.2 Page Titled

A

Supports

Document title element is populated from PDF metadata or filename, with url encoded characters cleaned for readability, e.g. %20 replaced with just a space.

2.4.3 Focus Order

A

Supports

Sequential focus follows DOM order.

2.4.4 Link Purpose (In Context)

A

Supports

Links have descriptive text; duplicate links clarify their target context.

2.4.5 Multiple Ways

AA

Supports

Document outline, search, and browser “find” provide multiple ways to locate content beyond sequential navigation.

2.4.6 Headings & Labels

AA

Supports

Headings describe topic or purpose; complex documents auto‑generate nested levels.

2.4.7 Focus Visible

AA

Supports

Clear focus indicator (2 px outline) is provided and meets contrast requirements.

2.5.1 Pointer Gestures

A

Supports

All actions can be completed with a single pointer; no multi‑finger gestures required.

2.5.2 Pointer Cancellation

A

Supports

Actions are not triggered until pointer release.

2.5.3 Label in Name

A

Supports

Visible labels match accessible names for all controls.

2.5.4 Motion Actuation

A

Not Applicable

No functionality relies on device motion.

3.1.1 Language of Page

A

Supports

“lang” attribute is set based on primary document language detected.

3.1.2 Language of Parts

AA

Supports

Inline lang tags are inserted for translated phrases or mixed‑language passages.

3.2.1 On Focus

A

Supports

Elements do not trigger unexpected context changes on focus.

3.2.2 On Input

A

Supports

Form interactions (admin dashboard) provide advance notice before navigating or submitting.

3.2.3 Consistent Navigation

AA

Supports

Navigation pattern remains consistent across documents.

3.2.4 Consistent Identification

AA

Supports

Components with identical functionality are identified consistently.

3.3.1 Error Identification

A

Supports

Admin input errors are described in text; focus moves to error summary.

3.3.2 Labels or Instructions

A

Supports

All inputs have programmatic labels.

3.3.3 Error Suggestion

AA

Supports

Error messages provide clear suggestions for correction.

3.3.4 Error Prevention (Legal, Financial, Data)

AA

Supports

Actions that modify or delete documents require explicit confirmation.

4.1.1 Parsing

A

Supports

Generated HTML validates against HTML5 via W3C Nu checker and Lighthouse; ARIA attributes follow specification.

4.1.2 Name, Role, Value

A

Supports

All custom components expose correct ARIA roles, names, states, and properties; dynamic updates fire relevant events.

4.1.3 Status Messages

AA

Supports

Dynamic alerts (e.g., language switch confirmation) are conveyed via role="status" or aria-live="polite".

302.1 Without Vision

Supports

Fully operable with screen readers; alternative transcript provides complete non‑visual access.

302.2 With Limited Vision

Supports

Reflow, zoom, and high‑contrast modes supported.

302.3 Without Perception of Color

Supports

No information conveyed solely through color.

302.4 Without Hearing

Supports

No audio content.

302.5 With Limited Hearing

Supports

Same as above.

302.6 Without Speech

Supports

Speech not required.

302.7 With Limited Manipulation

Supports

Keyboard operable; large clickable targets; no drag‑and‑drop required.

302.8 With Limited Reach & Strength

Supports

No time‑dependent, rapid gestures.

302.9 With Limited Language, Cognitive, & Learning Abilities

Supports

Plain‑language UI; Q&A feature accepts natural language questions and accommodates spelling errors.

602.2 Accessibility & Compatibility Features

Supports

Public documentation and FAQs describe screen‑reader, keyboard, and language features.

602.3 Electronic Support Documentation

Supports

Documentation is provided in HTML and PDF; HTML versions meet WCAG 2.1 AA.

602.4 Alternate Formats for Support Documentation

Supports

Documentation can be supplied in accessible Word, Braille, or large‑print upon request.

603.2 Information on Accessibility

Supports

Dedicated accessibility contact (support@docaccess.com) and phone line; VPAT publicly available.

603.3 Accommodation of Communication Needs

Supports

Users may request support via Aira live interpreters or Relay services.