Start free

Product accessibility

Accessibility statement

DocAccessible is committed to providing digital experiences that people with disabilities can use independently and effectively.

This statement covers our website and web application, explains the evidence we have today, names what remains unassessed, and tells you how to request an accessible alternative or report a barrier.

Target
WCAG 2.2 Level AA
Product-wide status
Not yet fully assessed
Assessment
Automated and manual testing
Last updated

Scope

What this statement covers

This statement covers DocAccessible-controlled pages at docaccessible.com, the signed-in web application, public request and delivery workflows, organization portal templates, and the interface around hosted documents. Responsive desktop and mobile variations are part of that scope.

Customer-provided source files and the meaning of generated document content need a separate document-level review. They are not made conformant by this platform statement. External checkout pages, linked services, and browser PDF viewers are also outside our direct control.

Ongoing work

Measures that support accessibility

  • Use semantic HTML and shared accessible components before adding WAI-ARIA.
  • Require visible keyboard focus, labelled controls, understandable errors, responsive reflow, and reduced-motion behavior in the design system.
  • Combine automated assessment with manual testing of keyboard access, focus management, forms, responsive layouts, and selected assistive-technology workflows.
  • Review accessibility during product changes, investigate reported barriers, and use what we learn to improve our components and testing practices.
  • Review this statement after material accessibility changes and at least quarterly.

Assessment

Our assessment approach

We use a combination of automated assessment and manual testing. Each method finds different kinds of barriers, so no single tool or test result is treated as proof of accessibility or conformance.

Automated assessment
Automated checks, including axe-core, help us identify common issues across representative public and signed-in pages. We also run interaction, type, lint, unit, build, and browser checks as part of the release process.
Manual testing
Manual testing is part of our approach. We review keyboard navigation, focus order and visibility, labels, instructions, errors, headings, landmarks, zoom, responsive reflow, and interaction behavior that automated tools cannot fully assess.
Assistive-technology testing
We test selected important workflows with assistive technologies and investigate the browser, device, and assistive-technology combinations people report to us. We are continuing to broaden this coverage over time.
Continuous improvement
Accessibility is ongoing work. As the product changes and we learn from testing and feedback, we work to improve the experience, our shared components, and the way we assess accessibility.

Our current assessment does not cover every WCAG success criterion, workflow, browser, device, or assistive-technology combination. We document known limitations and continue to strengthen our coverage without treating automated results as certification.

Technical information

Compatibility and technologies

DocAccessible relies on HTML, CSS, and JavaScript. We use WAI-ARIA when native HTML does not provide the semantics or state an interaction needs. Significant signed-in workflows require JavaScript; selected public content and navigation retain limited no-JavaScript behavior.

We combine automated checks with manual review and selected assistive-technology testing. We have not completed and published a product-wide compatibility matrix for every browser, screen reader, voice-control tool, magnifier, device, or operating-system combination. A reported combination is still in scope for investigation and support.

Known boundaries

Known limitations and available alternatives

Automated and manual testing can reveal barriers, but neither establishes that every experience is accessible in every context. These are the current areas where a person may need another route or additional support.

Customer-provided and generated document content

What you may experience
A hosted document can contain an incorrect reading order, heading level, table relationship, link purpose, or image description when the source or generated structure has not been reviewed.
Why
Software cannot reliably infer every relationship and every piece of meaning in a complex PDF.
What you can do now
Document owners should complete human review before publication. If a hosted document blocks you, send its URL through the barrier form or by email and ask for an accessible alternative.

Assistive-technology compatibility evidence

What you may experience
A workflow may behave differently with a browser, screen reader, voice-control tool, magnifier, or operating-system combination outside the current automated environment.
Why
We have not completed and published a product-wide manual compatibility matrix with named assistive-technology combinations.
What you can do now
Tell us the page, task, browser, operating system, and assistive technology involved. We will investigate the reported combination and help provide another route to the information or service.

Third-party and browser-provided experiences

What you may experience
Checkout pages, linked services, downloaded files, and built-in PDF viewers can expose controls or reading behavior that differs from DocAccessible's own interface.
Why
Those surfaces are operated or rendered by another provider and are not fully controlled by DocAccessible.
What you can do now
Contact us if an external step blocks completion. We will identify an available alternative or work with the provider where practical.

Standards and supporting guidance

How to read this statement

This statement is structured using the W3C Web Accessibility Initiative's guidance for developing accessibility statements. Our target is the Web Content Accessibility Guidelines (WCAG) 2.2. We use WAI's evaluation guidance to distinguish automated evidence from the human evaluation needed for conformance. We also use selected scope and reporting concepts from the WCAG Evaluation Methodology (WCAG-EM) 2.0. Our current assessment is not a complete evaluation conducted according to WCAG-EM 2.0 and is not a WCAG conformance evaluation, W3C certification, or independent audit.

Read the procurement accessibility status

Report a barrier or request an alternative

Include the page or document URL, the task you were trying to complete, what happened, and your browser, device, or assistive technology when relevant. You can also ask for information or a service in another accessible format.

We aim to acknowledge accessibility reports within two business days. Resolution time depends on the barrier. If the contact form itself is a barrier, email contact@docaccessible.com. Reply to the acknowledgement if the first response does not resolve the problem.

Report a barrier

Maintained through DocAccessible's internal engineering and accessibility review process. Last updated . We review this statement after material accessibility changes and at least quarterly.