Official sources reviewed
| Primary source | What it establishes | Review date |
|---|---|---|
| W3C WCAG 2.2 | Accessibility success criteria; not a product conformance statement. | 2026-07-22 |
What this decision is actually about
This is a workflow comparison more than a pure feature comparison. The real question is whether your team wants to keep paying the remediation tax after documents are generated, or shift compliance into the generation step itself.
Evaluation prompts—not a feature scorecard
| Alternative boundary | Confirm the supported input, deployment, and output behavior in the official source above using your current version. |
| PaperJSX boundary | Prove one real artifact locally first; local package behavior does not imply hosted access. |
| Delivery decision | Test the native file, recipient handoff, and release check that matter in your product. |
When PaperJSX is the better fit
PaperJSX is the strongest fit when accessibility has to be part of the generation contract itself, especially across multiple formats and in workflows where manual remediation would be too slow, expensive, or error-prone.
When manual remediation stacks is the better fit
For legacy documents that cannot be regenerated from source, manual remediation may still be necessary. PaperJSX prevents new accessibility debt from being created.
Cost of choosing PaperJSX
PaperJSX does not remediate existing legacy documents. Teams with large estates of historical content will still need remediation services for those files — but can stop the debt from growing on newly generated output.
Evaluate the file your customer receives.
Bring one real payload, its expected file, and the release check you cannot miss. Pro and Platform are self-serve; contact us when the evaluation requires Enterprise terms or architecture review.