PDF accessibility, remediation, pricing, and API questions

PDFAccessibility.ai checks PDFs for accessibility barriers, routes common issues through automated remediation, supports manual review for complex items, and exports corrected PDFs that can be re-checked outside the product.

The workflow is oriented around WCAG, PDF/UA, Section 508, ADA, and EN 301 549 expectations, including tags, reading order, headings, tables, links, document language, metadata, and image alternative text.

No. The product is designed for existing PDFs, including legacy files where the original Word, PowerPoint, InDesign, or source document is not available.

Automatic remediation is designed to be about 90% accurate for most common PDFs. Complex layouts, unusual tables, scanned pages, charts, forms, or ambiguous reading order may still need manual review before export.

No. The workflow should flag complex PDFs for review instead of hiding uncertainty. Automation handles the common fixes, while the manual editor is the fallback for issues that require human judgment.

Common automatic repairs include document structure tags, headings, reading order, metadata, language, lists, table structure, and image alt-text workflow support. Some visual or source-design problems still need the document creator to update the source file.

Manual review is intended for tags, roles, heading levels, reading order, accessible text, image alt text, tables, and review items that automation cannot safely decide on its own.

Yes. Manual edits must physically affect the exported PDF rather than only changing an internal score or dashboard state. The final artifact should contain the corrected tags, reading order, metadata, or alt text.

Use manual review for complex tables, charts, forms, scanned or OCR-heavy files, unusual layouts, ambiguous reading order, or any document where the automated result needs human verification before delivery.

After remediation, re-check the exported PDF. The goal is a physically corrected file that can pass an industry PDF/UA and WCAG validation workflow with no blocking errors.

Yes. A file can have optional advisory notices while still passing required blocking checks. Advisory items should be separated from true compliance-blocking errors so teams know what must be fixed before delivery.

No. Scores are useful for workflow, but final confidence comes from the exported PDF itself: tags, metadata, reading order, alt text, and structure must exist in the file and be externally verifiable.

Yes. PDF Accessibility plans are for checking, remediation, manual editing, and accessible PDF export. Developer API plans are for Smart PDF RAG parsing, JSON, Markdown, bounding boxes, and API usage.

Yes. Bundle and Enterprise options can include both PDF Accessibility and Developer API access. Paid users should see the workspace for the product they purchased, while bundle users may see both.

Use the pricing page for current product-fit guidance, limits, example usage scenarios, and billing questions. Enterprise teams can contact support for higher volume or workflow-specific requirements.

The Developer API is designed for structured PDF output such as JSON, Markdown, headings, paragraphs, table data, reading order, page references, and bounding boxes for search and RAG pipelines.

No. The API/RAG product focuses on structured extraction for developers. The PDF Accessibility product focuses on fixing and exporting accessible PDFs. Some teams may need both, but they are separate paid product tracks.

A strong first use case is converting PDFs into structured JSON and Markdown with page-level citation data so downstream search, review, or RAG systems can retrieve and cite content more reliably than plain text extraction.

Plain text often loses hierarchy, tables, page context, and visual position. Smart PDF RAG output keeps structure such as headings, tables, reading order, and bounding boxes so retrieval systems have better context.

Yes. The structured output is intended to preserve page references and layout metadata so search and RAG workflows can point users back to the source PDF location.

No. It is useful for developers, AI product teams, document intelligence workflows, knowledge-base ingestion, legal or policy review, and any system that needs structured PDF content instead of unorganized text.

Production workflows should use authenticated workspaces, secure transport, access controls, and retention policies appropriate for business documents. Use Enterprise support for organization-specific data handling requirements.

Use the same judgment you would use with any online document tool. For sensitive, regulated, or confidential files, use an authenticated paid workspace or contact the team about security and retention requirements before uploading.

Yes. The intended account model keeps PDF Accessibility and Developer API access separate unless a user has a bundle or Enterprise plan that includes both products.

Yes. Paid subscriptions should be cancellable through the billing flow. If you need help with account or billing access, contact support from the workspace or email the team.

Yes. Teams that start with one product can move to a bundle or Enterprise setup if they need both accessible PDF export and Smart PDF RAG/API output.

Plan-specific usage rules should be checked on the pricing page or in your account. Enterprise plans can be tailored for higher-volume document queues or API workloads.

Enterprise is best for organizations with high document volume, multiple operators, batch remediation needs, strict validation workflows, custom API usage, or security and procurement requirements.

Yes. The product is designed around a repeatable check, remediate, manual review, re-check, and export workflow that can support teams handling document backlogs for clients or departments.

Use the support page if you have workspace access, or email [email protected] for product, billing, API, or Enterprise questions.