# DocAccessible complete public product documentation > A consolidated, plain-text rendering of DocAccessible product documentation for retrieval tools and AI agents that need more context than the curated llms.txt index. Canonical site: https://docaccessible.com Curated index: https://docaccessible.com/llms.txt Content review date: 2026-08-21 This file contains public product guidance only. It excludes authenticated workspaces, private documents, customer data, tokens, and API responses. Canonical HTML pages remain the source to cite and share. ## Safety and conformance boundaries - Automated checking and remediation assist accessibility work; they do not certify conformance. - Preserve unresolved manual-review findings until a qualified person has evaluated them with representative assistive technology and tasks. - Rebuilt tagged PDFs may reflow. Use separately scoped specialist remediation when exact pagination, forms, or presentation must remain intact. - Published alternatives are deliberate, version-bound actions. Discovery or processing alone does not make a document public. ## Documentation index ### Start here - [Get started with DocAccessible](https://docaccessible.com/docs/getting-started): Set up your workspace, choose the right workflow, and complete your first useful accessibility task. - [Use the free PDF accessibility checker](https://docaccessible.com/docs/free-pdf-checker): Run a bounded structural inspection, interpret passed, failed, and manual-review findings, and decide the next remediation step. - [Understand automation, conformance, and manual remediation](https://docaccessible.com/docs/accessibility-boundaries): Know what DocAccessible automates, what still requires human validation, and when exact-layout manual PDF remediation is the right path. ### Documents - [Upload and remediate a document](https://docaccessible.com/docs/upload-and-remediate): Upload a PDF or DOCX, follow processing, and understand the outputs created by automated remediation. - [Review findings and edit accessible content](https://docaccessible.com/docs/review-findings-and-edit): Interpret the automated score, resolve structure and alt-text issues, and save a new reviewed version. - [Publish and share accessible output](https://docaccessible.com/docs/publish-and-share): Choose visibility, publish hosted HTML, and create controlled share links without exposing the private original. - [Organize documents, folders, activity, and versions](https://docaccessible.com/docs/document-library-and-versions): Use the library to find documents, group work, inspect activity, and understand immutable version history. - [Monitor processing jobs and retry failures](https://docaccessible.com/docs/processing-jobs-and-retries): Understand queued, running, completed, and failed remediation jobs and retry only when it is safe. ### Website monitoring - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup): Verify a public domain, install the lightweight script, and begin building a bounded PDF inventory. - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script): Choose the right installation method, add the generated script once, and verify that DocAccessible can see it in your public page source. - [Install the website script on WordPress](https://docaccessible.com/docs/install-script-wordpress): Add the DocAccessible script across a WordPress site using a managed code area or a child-theme hook, then clear caches and verify the public HTML. - [Install the website script on Shopify](https://docaccessible.com/docs/install-script-shopify): Add the generated DocAccessible tag to Shopify theme.liquid, publish the correct theme, and verify it on the public storefront. - [Install the website script on Webflow](https://docaccessible.com/docs/install-script-webflow): Use Webflow's site-level Footer code, publish to the connected custom domain, and confirm the site key in the live page source. - [Install the website script on Wix](https://docaccessible.com/docs/install-script-wix): Add DocAccessible through Wix Custom Code on every page, place it at Body - end, and verify the published connected domain. - [Install the website script on Squarespace](https://docaccessible.com/docs/install-script-squarespace): Add the generated tag through Squarespace Footer code injection, save it site-wide, and verify a public page outside the editor. - [Install the website script on Drupal or Joomla](https://docaccessible.com/docs/install-script-drupal-joomla): Add DocAccessible through the active CMS theme or asset manager, preserve the site-key attribute, clear caches, and verify rendered source. - [Install the website script on a custom-built site](https://docaccessible.com/docs/install-script-custom-sites): Add the generated tag to static HTML, shared server templates, React or Vite entry HTML, or a Next.js root layout without breaking verification. - [Tag managers and client-only script installation](https://docaccessible.com/docs/script-installation-tag-managers): Understand why Google Tag Manager and runtime-only injection cannot complete secure website verification, and move the tag to a supported global template. - [Review website PDF inventory and source changes](https://docaccessible.com/docs/website-pdf-inventory): Prioritize discovered PDFs, read scan history, handle plan limits, and respond when a public source changes. - [Convert a discovered PDF and publish an accessible alternative](https://docaccessible.com/docs/publish-website-alternatives): Create a private remediation draft from a public PDF, review it, and explicitly map one completed version for website visitors. ### Exchange - [Create and manage an Exchange case](https://docaccessible.com/docs/exchange-cases): Set acceptance criteria, invite a scoped vendor, and keep source files, deadlines, and activity in one controlled case. - [Review, approve, and deliver Exchange work](https://docaccessible.com/docs/exchange-review-and-delivery): Compare immutable revisions, verify evidence, request changes, approve the right submission, and create controlled delivery access. ### Collaboration - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval): Assign a reviewer, track due work, request changes, and bind approval to the version that was actually reviewed. - [Collect and resolve reader accessibility feedback](https://docaccessible.com/docs/accessibility-feedback): Use hosted-document feedback to reproduce barriers, assign ownership, record resolution, and close the loop with readers. - [Run an accessibility program hub](https://docaccessible.com/docs/program-hub): Collect client requests, choose a defensible remediation path, coordinate work across workspaces, and record version-bound release evidence. - [Set up an organization document portal](https://docaccessible.com/docs/organization-portals): Reserve a managed organization hostname, invite your team, configure the public directory, and publish reviewed document versions safely. ### Account and operations - [Manage workspaces, members, invitations, and roles](https://docaccessible.com/docs/members-workspaces-and-roles): Keep work in the right workspace, invite teammates, assign least-privilege roles, and transfer ownership carefully. - [Manage account access, security, export, and deletion](https://docaccessible.com/docs/account-security-and-data): Verify account access, recover or change a password, export your documents, and understand permanent account deletion. - [Use API keys and signed webhooks](https://docaccessible.com/docs/api-keys-and-webhooks): Create scoped integration credentials, verify signed webhook deliveries, and operate integrations without exposing secrets. - [Understand plans, billing, and usage limits](https://docaccessible.com/docs/plans-billing-and-usage): Read workspace allowances, choose a plan, start checkout, and understand which limits apply to each workflow. - [Get support and report an accessibility barrier](https://docaccessible.com/docs/contact-support): Send enough context for a useful response without putting confidential documents or sensitive credentials into the contact form. ## Documentation articles ### Get started with DocAccessible Canonical URL: https://docaccessible.com/docs/getting-started Set up your workspace, choose the right workflow, and complete your first useful accessibility task. - Category: Start here - Audience: New workspace owners and contributors - Estimated time: 10 minutes #### Prerequisites - A verified DocAccessible account - A PDF or DOCX you are permitted to upload, or a public website you manage #### Procedure 1. **Confirm the active workspace.** Use the workspace switcher in the app header before creating documents, sites, or Exchange cases. Every record belongs to the active workspace. 2. **Choose the workstream.** Use Documents for automated checking and editable output, Website monitoring for public PDF inventory, or Exchange for vendor-managed remediation. 3. **Start with one real task.** Upload one representative document, connect one verified website, or create one Exchange case. Small first runs make the review and publishing boundaries easier to understand. 4. **Review before publishing.** Treat automated findings and generated output as assistance. Resolve manual-review items and validate important content with people and assistive technology before release. #### What the dashboard shows The dashboard brings document usage, website inventory, Exchange capacity, priority findings, recent work, and the next recommended action into one view. Plan limits are workspace-specific. A visible button does not override an API entitlement or role requirement. #### Private by default Uploaded originals and generated drafts remain private until an authorized user explicitly changes visibility or creates a share link. Website discoveries also remain workspace records until a completed version is deliberately mapped for publication. #### Related documentation - [Upload and remediate a document](https://docaccessible.com/docs/upload-and-remediate) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Create and manage an Exchange case](https://docaccessible.com/docs/exchange-cases) ### Upload and remediate a document Canonical URL: https://docaccessible.com/docs/upload-and-remediate Upload a PDF or DOCX, follow processing, and understand the outputs created by automated remediation. - Category: Documents - Audience: Document owners and remediation contributors - Estimated time: 5 minutes plus processing #### Prerequisites - An active plan with remaining remediation allowance - A supported PDF or DOCX within the plan file-size limit #### Procedure 1. **Open Start new work.** From the dashboard, go to the upload area. If you selected a folder first, new documents are placed in that folder. 2. **Select or drop files.** Choose one or more PDF or DOCX files. The browser shows each file's queued, uploading, completed, or failed state. 3. **Wait for a terminal result.** The private original is validated and queued for isolated processing. The document page updates when the job succeeds or fails. 4. **Review the generated version.** Open the document to inspect its score, machine-detectable findings, AI source comparison when available, unresolved manual checks, hosted HTML, rebuilt tagged PDF, and audit report. #### Outputs and their purpose Hosted HTML is responsive, editable, and usually the strongest reading experience. The rebuilt tagged PDF is intended for offline use and may reflow or simplify the original layout. - The original file remains private storage input. - Each completed run creates an immutable version. - The audit report records automated evidence, not certification. #### How AI source comparison works For eligible PDFs, a constrained structure pass can propose only complete block order or heading and paragraph classification. A separate fidelity pass compares the final blocks with the original PDF and reports content, semantic, and reading-order confidence plus a conservative route. The confidence values are review signals, not accessibility scores or permission to publish. Provider failure, configured limits, and editor changes leave an explicit manual source-comparison requirement instead of silently reusing confidence. #### If an upload is rejected Check the real file type, file size, remaining monthly allowance, and whether the current plan includes automated remediation. A renamed or damaged file can fail content validation even when its extension looks correct. #### Related documentation - [Review findings and edit accessible content](https://docaccessible.com/docs/review-findings-and-edit) - [Monitor processing jobs and retry failures](https://docaccessible.com/docs/processing-jobs-and-retries) - [Understand plans, billing, and usage limits](https://docaccessible.com/docs/plans-billing-and-usage) ### Review findings and edit accessible content Canonical URL: https://docaccessible.com/docs/review-findings-and-edit Interpret the automated score, resolve structure and alt-text issues, and save a new reviewed version. - Category: Documents - Audience: Remediation contributors and accessibility reviewers - Estimated time: Varies by document #### Prerequisites - A document with a completed processed version #### Procedure 1. **Open a completed document.** Select the document from the library and begin with critical and needs-review findings rather than the score alone. 2. **Inspect structure and context.** Check headings, reading sequence, lists, links, tables, image purpose, document language, and any item that software could not responsibly decide. When AI source comparison is available, review its exact concerns and route without treating confidence as conformance. 3. **Open Edit.** Use the findings rail to jump to affected blocks, then correct headings, text, alt text, captions, table structure, lists, callouts, and reading order. Switch to Preview to inspect the unsaved accessible output, draft score, heading outline, and reading sequence before creating a version. AI-generated image descriptions are drafts and need contextual review. 4. **Save and recheck.** Saving creates a new immutable version and reruns applicable deterministic checks. If blocks changed, the prior AI source comparison becomes stale because it was bound to the earlier output. Revisit unresolved manual items before publishing or requesting approval. #### How to use the score The score is a prioritization signal based on available automated evidence. It is not proof of WCAG, PDF/UA, ADA, or Section 508 conformance, and it should not be used as the only release gate. #### Manual review still matters Reading order, complex tables, charts, forms, language changes, meaningful image descriptions, and the assistive-technology experience can require a qualified person. Keep those decisions visible in your review record. #### Related documentation - [Upload and remediate a document](https://docaccessible.com/docs/upload-and-remediate) - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) - [Understand automation, conformance, and manual remediation](https://docaccessible.com/docs/accessibility-boundaries) ### Publish and share accessible output Canonical URL: https://docaccessible.com/docs/publish-and-share Choose visibility, publish hosted HTML, and create controlled share links without exposing the private original. - Category: Documents - Audience: Document owners and publishers - Estimated time: 5 minutes #### Prerequisites - A completed document version that has been reviewed for release #### Procedure 1. **Choose the delivery format.** Use hosted HTML for responsive online reading. Use the rebuilt tagged PDF when an offline file is required and layout changes are acceptable. 2. **Set document visibility.** Keep the canonical hosted page private, make it unlisted, or publish it publicly. A separate viewing link can provide revocable access to a private document without changing that visibility. 3. **Create a viewing link when needed.** Create a view-only link for someone outside the workspace, choose an expiry, and add a password on eligible plans. Viewing links never grant editing access; invite an authenticated workspace member when collaboration is required. 4. **Test the reader experience.** Open the published URL in a private browser window and check keyboard navigation, headings, links, zoom, mobile reflow, and representative assistive technology. #### Publication and versions A later edit creates a new version. Existing review decisions remain bound to the version that was reviewed, so confirm the current version before release. #### Revoke access Revoke a viewing link when that recipient no longer needs access. The token, protected document view, and token-bound file downloads stop working immediately. Separately return the canonical page to private when public or unlisted access should also end. #### Related documentation - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) - [Organize documents, folders, activity, and versions](https://docaccessible.com/docs/document-library-and-versions) - [Collect and resolve reader accessibility feedback](https://docaccessible.com/docs/accessibility-feedback) ### Organize documents, folders, activity, and versions Canonical URL: https://docaccessible.com/docs/document-library-and-versions Use the library to find documents, group work, inspect activity, and understand immutable version history. - Category: Documents - Audience: All workspace users - Estimated time: 5 minutes #### Prerequisites - At least one uploaded document for version and activity examples #### Procedure 1. **Filter the library.** Search by title, slug, or visibility. Use All documents, Uncategorized, or a named folder to narrow the list. 2. **Create folders.** Add a folder for a department, release, owner, or campaign. Deleting a folder does not delete its documents; they become uncategorized. 3. **Move a document.** Open the document and use its folder control to place it in another collection without changing the document URL or version. 4. **Review activity and versions.** Use the activity timeline for meaningful lifecycle events and version history for immutable output snapshots and scores. #### Version rules Edits and new remediation outputs create versions rather than overwriting review evidence. Approval, website publication, and other release decisions must refer to the exact intended version. #### Related documentation - [Review findings and edit accessible content](https://docaccessible.com/docs/review-findings-and-edit) - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) - [Monitor processing jobs and retry failures](https://docaccessible.com/docs/processing-jobs-and-retries) ### Request review and approve an exact version Canonical URL: https://docaccessible.com/docs/review-and-approval Assign a reviewer, track due work, request changes, and bind approval to the version that was actually reviewed. - Category: Collaboration - Audience: Owners, admins, contributors, and assigned reviewers - Estimated time: 5 minutes to set up #### Prerequisites - A completed document version - A plan and workspace role that permit review workflows #### Procedure 1. **Open the document review panel.** From a completed document, create a review for the current version and choose an eligible workspace member. 2. **Add context and a due date.** Describe the release decision the reviewer is making and add a realistic due date when timing matters. 3. **Review the exact version.** The reviewer checks findings, content, output, and required manual evidence before approving or requesting changes. 4. **Treat superseded reviews correctly.** If a newer version is created, the earlier approval does not transfer. Start or complete a review for the new version. #### Use the review queue The Reviews page separates work assigned to you from requests you created. Status, due date, reviewer, version, and superseded state remain visible for follow-up. #### What approval means Approval records a workspace decision about an exact version. It does not certify accessibility and does not replace the manual validation required by the document's purpose and risk. #### Related documentation - [Review findings and edit accessible content](https://docaccessible.com/docs/review-findings-and-edit) - [Publish and share accessible output](https://docaccessible.com/docs/publish-and-share) - [Manage workspaces, members, invitations, and roles](https://docaccessible.com/docs/members-workspaces-and-roles) ### Monitor processing jobs and retry failures Canonical URL: https://docaccessible.com/docs/processing-jobs-and-retries Understand queued, running, completed, and failed remediation jobs and retry only when it is safe. - Category: Documents - Audience: Document owners and operators - Estimated time: 3 minutes #### Prerequisites - At least one uploaded document #### Procedure 1. **Open Processing jobs.** Use the app's More menu or a failed document's View history link to inspect recent work. 2. **Read the terminal state.** Queued and running jobs should progress automatically. Succeeded jobs have version outputs. Failed jobs display sanitized, user-safe context. 3. **Retry once after a transient failure.** Use Retry when the UI offers it. The system creates a new processing attempt without pretending the failed attempt succeeded. 4. **Escalate repeated failures.** If the same file fails again, contact support with the document title, approximate time, and visible error. Do not email confidential source files. #### Common causes Damaged files, unsupported structures, malware-scan failures, parser limits, provider failures, or worker resource limits can stop processing. Raw system errors and document content are intentionally not exposed in the browser. #### Related documentation - [Upload and remediate a document](https://docaccessible.com/docs/upload-and-remediate) - [Get support and report an accessibility barrier](https://docaccessible.com/docs/contact-support) - [Understand automation, conformance, and manual remediation](https://docaccessible.com/docs/accessibility-boundaries) ### Connect a website and install PDF monitoring Canonical URL: https://docaccessible.com/docs/website-monitoring-setup Verify a public domain, install the lightweight script, and begin building a bounded PDF inventory. - Category: Website monitoring - Audience: Website owners and workspace admins - Estimated time: 10-20 minutes #### Prerequisites - Control of a public website - Permission to add one script tag to the site's pages or template #### Procedure 1. **Connect the public domain.** Enter the website origin in Website monitoring. The entered host becomes the crawl origin and consumes the applicable domain allowance. 2. **Copy the generated script tag.** Open the connected website, copy its exact installation code, then use the platform-specific guide to add it once to the global footer or shared server-rendered template. 3. **Load a page on the connected domain.** The first same-domain report starts verification. The server fetches that page and confirms the matching key is present on the script tag. 4. **Confirm verification and inventory.** Return to the site dashboard. After verification, discoveries and bounded scans appear asynchronously as visitors or scheduled checks encounter PDF links. #### What the script observes The script reports normalized PDF URLs and the same-domain page where each link appears. It does not collect visitor identity, cookies, form values, or page content. #### Verification requirements A browser Origin header is not ownership proof. The public page must load the matching script key, and outbound fetching stays inside the connected domain and its allowed subdomains. #### Choose your website platform Use the guide that matches the system responsible for the final public HTML. Every route ends with the same check: open a public page, view its source, and confirm the exact generated site key is present before waiting for verification. - [WordPress](https://docaccessible.com/docs/install-script-wordpress): Use a site-wide code tool or a child-theme hook without editing the parent theme. - [Shopify](https://docaccessible.com/docs/install-script-shopify): Add the generated tag to theme.liquid and keep the change with the active theme. - [Webflow](https://docaccessible.com/docs/install-script-webflow): Use site-level Footer code, publish the site, and verify the custom domain. - [Wix](https://docaccessible.com/docs/install-script-wix): Add custom code to every page at Body - end and confirm it survives publication. - [Squarespace](https://docaccessible.com/docs/install-script-squarespace): Use site-wide Footer code injection on an eligible plan. - [Drupal or Joomla](https://docaccessible.com/docs/install-script-drupal-joomla): Install through the active theme or the CMS asset manager and clear caches. - [Custom HTML, React, Next.js, and server frameworks](https://docaccessible.com/docs/install-script-custom-sites): Place the script in the shared server-rendered layout so it appears in page source. - [Google Tag Manager and client-only injection](https://docaccessible.com/docs/script-installation-tag-managers): Understand why runtime-only tags cannot complete verification and choose a supported route. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Review website PDF inventory and source changes](https://docaccessible.com/docs/website-pdf-inventory) - [Convert a discovered PDF and publish an accessible alternative](https://docaccessible.com/docs/publish-website-alternatives) ### Install the website monitoring script Canonical URL: https://docaccessible.com/docs/install-website-script Choose the right installation method, add the generated script once, and verify that DocAccessible can see it in your public page source. - Category: Website monitoring - Audience: Website administrators, developers, and agency partners - Estimated time: 10-30 minutes #### Prerequisites - A connected website in DocAccessible - The exact installation code copied from that website's Installation tab - Permission to publish site-wide code on the connected public domain #### Procedure 1. **Open the connected website.** In Website monitoring, select the domain you are installing and open Installation. Do not reuse code from another connected website because every domain has a different public site key. 2. **Copy the complete generated tag.** Choose Copy installation code. Keep the script URL, async attribute, and data-site-key exactly as generated. 3. **Choose the global installation point.** Use your CMS's site-wide Footer or Body - end code area, the shared server-rendered layout, or the active theme's supported asset system. Add the tag once, not once per PDF. 4. **Publish the website change.** Save and publish the real production site. Clear application, CMS, host, and CDN caches when they can continue serving older HTML. 5. **Open a public page on the connected domain.** Visit a normal public page that includes the script. This first browser report starts verification and provides the exact page that DocAccessible will fetch. 6. **Confirm source and connection status.** Use View page source and search for your data-site-key. Then return to Installation and wait for Script connected. Only after verification can scheduled checking and approved visitor mappings operate normally. #### What the generated code looks like The example below shows the shape of the tag. YOUR_SITE_KEY is only a placeholder. Always paste the exact code from the connected website so the service origin and key match your workspace record. **Example only - use the code from your Installation tab** ~~~text ~~~ #### Choose your platform Select the system that produces the public website. If an agency, managed host, or custom theme controls the final HTML, send them the custom-site guide together with the generated tag. - [WordPress](https://docaccessible.com/docs/install-script-wordpress): Use a site-wide code tool or a child-theme hook without editing the parent theme. - [Shopify](https://docaccessible.com/docs/install-script-shopify): Add the generated tag to theme.liquid and keep the change with the active theme. - [Webflow](https://docaccessible.com/docs/install-script-webflow): Use site-level Footer code, publish the site, and verify the custom domain. - [Wix](https://docaccessible.com/docs/install-script-wix): Add custom code to every page at Body - end and confirm it survives publication. - [Squarespace](https://docaccessible.com/docs/install-script-squarespace): Use site-wide Footer code injection on an eligible plan. - [Drupal or Joomla](https://docaccessible.com/docs/install-script-drupal-joomla): Install through the active theme or the CMS asset manager and clear caches. - [Custom HTML, React, Next.js, and server frameworks](https://docaccessible.com/docs/install-script-custom-sites): Place the script in the shared server-rendered layout so it appears in page source. - [Google Tag Manager and client-only injection](https://docaccessible.com/docs/script-installation-tag-managers): Understand why runtime-only tags cannot complete verification and choose a supported route. #### The page-source check that matters DocAccessible does not treat a browser request alone as proof that you control the domain. Its worker fetches the reported public page and looks for the official script URL with the exact site key in the returned HTML. - Use View page source, not only the browser Elements panel. - Search for data-site-key and compare the complete value with the Installation tab. - Confirm the page URL uses the same connected host and HTTPS origin. - Do not install only through a tag manager, useEffect, or another client-only loader. #### Content Security Policy A restrictive Content Security Policy must allow the exact DocAccessible origin shown in your generated tag. Merge the origin into the existing directives; do not replace the website's complete policy with this example. - script-src permits the browser to load /site/v1.js. - connect-src permits inventory reports and approved viewer requests. - img-src permits images in an approved accessible viewer. **CSP directive example** ~~~text script-src 'self' https://docaccessible.com; connect-src 'self' https://docaccessible.com; img-src 'self' data: https://docaccessible.com; ~~~ #### If verification does not complete Start with the source check because it separates publishing problems from network or policy problems. After each correction, open a fresh public page and return to the Installation tab. - Wrong key: remove old or duplicate tags and paste the current connected website's code. - Missing from source: move the tag from a client-only component into the CMS global code area or server-rendered layout. - Old source: purge page, host, reverse-proxy, and CDN caches, then reload in a private window. - Blocked request: inspect the browser console for Content Security Policy, extension, consent, or network errors. - Wrong host: install and open a page on the exact connected domain, including the intended www or non-www host. - Private page: choose a publicly reachable page without authentication, maintenance mode, or an IP allowlist. #### Move or remove the installation safely Keep only one copy of the script per rendered page. When changing themes or platforms, install and verify the tag in the replacement before removing the old implementation. Disconnecting the website removes its inventory and viewer mappings. Removing only the script stops new browser discoveries but does not automatically delete workspace records. #### Related documentation - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Install the website script on a custom-built site](https://docaccessible.com/docs/install-script-custom-sites) - [Tag managers and client-only script installation](https://docaccessible.com/docs/script-installation-tag-managers) ### Install the website script on WordPress Canonical URL: https://docaccessible.com/docs/install-script-wordpress Add the DocAccessible script across a WordPress site using a managed code area or a child-theme hook, then clear caches and verify the public HTML. - Category: Website monitoring - Audience: WordPress administrators, developers, and managed-host teams - Estimated time: 10-25 minutes #### Prerequisites - Administrator or deployment access to the WordPress site - The generated installation code for this exact domain - A current backup or staging environment before editing theme code #### Procedure 1. **Copy the generated installation code.** Open the connected website in DocAccessible, choose Installation, and copy the complete tag. Keep the site key unchanged. 2. **Use the site's supported global-code method.** If your managed host or active theme provides a site-wide footer or body-end code area, use that supported tool. Configure it for the public front end and every page. 3. **Use a child theme when code is required.** Ask a WordPress developer to add the tag through a child theme or a small site-owned plugin. Do not edit the parent theme because an update can erase the change. 4. **Publish and clear every cache layer.** Save the change, deploy it, and purge WordPress page caches, optimization plugins, managed-host caches, and the CDN when present. 5. **Check a logged-out public page.** Open a normal page in a private window, use View page source, and search for the exact data-site-key. Admin previews can differ from cached visitor HTML. 6. **Confirm Script connected.** Reload the public page once, then return to the website Installation tab. If verification fails, compare the page-source key before changing anything else. #### Choose the safest WordPress method WordPress core does not provide one universal site-wide script field. Managed hosts, commercial themes, and governance plugins expose different labels, so prefer the installation mechanism already approved for that site. - Best for site admins: an existing site-wide Footer or Body - end code area. - Best for development teams: a child theme or small site-owned plugin under version control. - Avoid: editing footer.php or functions.php in the parent theme. - Avoid: adding a Custom HTML block to one page, because monitoring should cover the shared template. #### Optional child-theme hook A developer can add the exact generated tag from the child theme's functions.php. Replace the placeholder tag below with the installation code copied from DocAccessible, then review it through the normal deployment process. **Child theme functions.php example** ~~~text function docaccessible_add_site_script() { ?> . Do not put it inside a product, collection, or section template that renders only on some pages. 5. **Save, preview, and publish the intended theme.** Save the file. If you edited a duplicate theme, preview it first and publish that theme only after confirming the storefront still works normally. 6. **Verify the live storefront source.** Open a public storefront page without the theme preview parameter, view page source, search for data-site-key, then return to DocAccessible and confirm Script connected. #### Placement in theme.liquid The installation belongs at the end of the shared storefront layout. Use the tag from DocAccessible in place of the placeholder example. **Layout/theme.liquid placement** ~~~text ~~~ #### Theme updates and replacements Shopify theme code belongs to a specific theme. A newly installed or updated theme copy may not include edits made to the previous theme, so add script verification to the store's theme-release checklist. - Confirm the tag before publishing a replacement theme. - Keep the code in only one global layout to avoid duplicate reports. - Recheck page source after a theme migration or domain change. - Storefront theme code does not control every Shopify-hosted checkout surface. #### Shopify troubleshooting The most common failure is editing a draft while a different theme remains live. Compare the active theme name, open the normal public storefront, and verify the source outside the theme preview. #### Official Shopify reference Shopify recommends editing theme code only when the required change cannot be made through the theme editor or an approved app, and warns that incompatible custom edits can be lost in an updated theme copy. - [Shopify: Edit theme code](https://help.shopify.com/en/manual/online-store/themes/customizing-themes/edit-code/edit-theme-code): Open, search, edit, and manage files in the current Shopify theme. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Review website PDF inventory and source changes](https://docaccessible.com/docs/website-pdf-inventory) ### Install the website script on Webflow Canonical URL: https://docaccessible.com/docs/install-script-webflow Use Webflow's site-level Footer code, publish to the connected custom domain, and confirm the site key in the live page source. - Category: Website monitoring - Audience: Webflow site owners, designers, and agency publishers - Estimated time: 10-15 minutes #### Prerequisites - Access to the Webflow site's custom-code settings - A published custom domain that matches the connected website - The exact generated installation code from DocAccessible #### Procedure 1. **Copy the generated tag.** Open the connected domain in DocAccessible, choose Installation, and copy the complete script tag. 2. **Open site-level Custom code.** Open the Webflow site settings and choose Custom code. Use the site-level area rather than an individual page setting so new and existing pages receive the script. 3. **Paste into Footer code.** Paste the tag into the Footer code area, which Webflow places before the closing body tag. Keep only one copy. 4. **Save the custom code.** Save the setting, then review other global scripts for a Content Security Policy or consent loader that may block the DocAccessible origin. 5. **Publish to the connected domain.** Publish the Webflow site and select the exact custom domain connected in DocAccessible. A Designer preview or saved draft is not enough. 6. **Verify the published page.** Open a public page on that domain, view page source, find the site key, and return to Installation to confirm the connection. #### Use site-level code, not page-only code Page settings can add custom code to one Webflow page, but monitoring needs the shared site-level Footer code so PDF links can be discovered throughout the site. - Site-level Footer code: recommended. - Individual page Before code: use only for a deliberately limited subsite and expect incomplete inventory. - Embed element inside page content: not a global installation method. #### Publish and source check Webflow can show custom-code effects in preview, but the change is not public until the site is published. Verify the custom domain rather than the Designer or staging canvas. **Footer code example** ~~~text ~~~ #### Official Webflow reference Webflow's current guidance places general script tags in the Footer code area before the closing body tag and requires publication before the code is live. - [Webflow: Custom code in head and body tags](https://help.webflow.com/hc/en-us/articles/33961357265299): Review site-level and page-level custom-code placement and publishing behavior. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Tag managers and client-only script installation](https://docaccessible.com/docs/script-installation-tag-managers) ### Install the website script on Wix Canonical URL: https://docaccessible.com/docs/install-script-wix Add DocAccessible through Wix Custom Code on every page, place it at Body - end, and verify the published connected domain. - Category: Website monitoring - Audience: Wix site owners, administrators, and agency partners - Estimated time: 10-20 minutes #### Prerequisites - A published Wix site with a connected custom domain - Access to Development and integrations settings - The generated installation code for that exact domain #### Procedure 1. **Copy the generated tag.** Open the connected Wix domain in DocAccessible and copy the complete Installation code. 2. **Open Wix Custom Code.** From the site's dashboard, open Settings. In Development and integrations, choose Custom Code, then Add Custom Code. 3. **Name and paste the code.** Use a clear name such as DocAccessible website monitoring and paste the exact generated tag into the code field. 4. **Apply it to all pages.** Choose All pages, including future pages, and configure it to load on each page a visitor opens so each public location can report its current PDF links. 5. **Choose Body - end and apply.** Under placement, choose Body - end. Apply the change and publish the site if Wix requests publication. 6. **Verify the connected domain.** Open a public page on the primary connected domain, check page source for the site key, and return to DocAccessible to confirm Script connected. #### Required Wix settings The script should be invisible and global. Do not use an Embed HTML element because embeds run inside a separate iframe and cannot inventory links in the main Wix page. - Add Code to Pages: All pages - Frequency: each page a visitor opens - Place Code in: Body - end - Domain: the primary domain connected in DocAccessible **Wix Custom Code value** ~~~text ~~~ #### Wix security and domain changes Wix introduced additional frontend security checks for custom code in December 2025. If the saved tag is missing or blocked, check the Wix code status, browser console, CSP messages, and whether the site uses the same primary domain. Wix associates custom-code snippets with a domain. Recheck the installation after assigning a different primary domain. #### Official Wix reference Wix's current Custom Code workflow supports all-page installation and Head, Body - start, or Body - end placement. - [Wix: Embedding Custom Code on Your Site](https://support.wix.com/en/article/wix-editor-embedding-custom-code-on-your-site): Review the dashboard path, page scope, loading frequency, placement, and current security notes. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Tag managers and client-only script installation](https://docaccessible.com/docs/script-installation-tag-managers) ### Install the website script on Squarespace Canonical URL: https://docaccessible.com/docs/install-script-squarespace Add the generated tag through Squarespace Footer code injection, save it site-wide, and verify a public page outside the editor. - Category: Website monitoring - Audience: Squarespace owners, contributors with code access, and agencies - Estimated time: 10-15 minutes #### Prerequisites - A Squarespace plan and contributor role that allow Code Injection - The generated installation code for the connected domain - A publicly reachable page outside password or maintenance protection #### Procedure 1. **Copy the exact generated tag.** Open the connected Squarespace domain in DocAccessible and copy its Installation code. 2. **Open Code Injection.** Open the Squarespace Code Injection panel from site settings. If menu labels differ, search settings for Code Injection rather than adding a Code Block to page content. 3. **Paste into Footer.** Paste the complete script into the site-wide Footer field. Squarespace injects this field before the closing body tag on supported public pages. 4. **Save the setting.** Save the Code Injection panel. Keep the tag outside consent wrappers that prevent it from loading unless your governance policy explicitly requires that behavior. 5. **Open the public site.** Visit a normal page in a private window, not the editor preview. View page source and search for the exact data-site-key. 6. **Confirm verification.** Reload the public page once and return to DocAccessible. If the key is absent from source, confirm plan access, save state, page type, and site password settings. #### Use Footer code injection Footer code injection is site-wide and is the correct location for the generated tag. A Code Block is page content and can be restricted by plan, editor state, or the page where it was placed. **Squarespace Footer value** ~~~text ~~~ #### Squarespace limitations to check Code Injection availability depends on the site plan. Squarespace also states that checkout pages do not support injected code, so verify monitoring on normal content, collection, or resource pages. - Test while logged out or in a private window. - Use a public page without a site-wide password. - Check whether a cookie or consent rule blocks the script before it reports. - Recheck after a template or domain migration. #### Official Squarespace reference Squarespace's current guide documents site-wide Footer injection, eligible plans, and page types that do not accept injected code. - [Squarespace: Using code injection](https://support.squarespace.com/hc/en-us/articles/205815908-Using-code-injection): Review the current Code Injection fields, plan access, saving, and platform limitations. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Tag managers and client-only script installation](https://docaccessible.com/docs/script-installation-tag-managers) ### Install the website script on Drupal or Joomla Canonical URL: https://docaccessible.com/docs/install-script-drupal-joomla Add DocAccessible through the active CMS theme or asset manager, preserve the site-key attribute, clear caches, and verify rendered source. - Category: Website monitoring - Audience: Drupal and Joomla developers, site builders, and platform teams - Estimated time: 20-40 minutes #### Prerequisites - Development and deployment access to the active CMS theme or extension - A tested rollback path before changing production templates - The exact generated installation code for the connected domain #### Procedure 1. **Identify the active public theme.** Confirm which theme or template renders anonymous front-end pages. Admin themes and inactive templates do not affect public page source. 2. **Copy the generated installation values.** From DocAccessible Installation, copy the complete tag. Preserve both the service URL and data-site-key when translating it into the CMS asset configuration. 3. **Register the external script globally.** Use Drupal's library system or Joomla's Web Asset Manager in the active theme or a site-owned extension. Set async and the custom data-site-key attribute. 4. **Deploy and rebuild caches.** Deploy through the site's normal release process, then clear Drupal or Joomla caches, template caches, reverse proxies, and the CDN. 5. **Verify anonymous page source.** Open a public page as a logged-out visitor and search its source for the exact key. Do not rely only on an authenticated toolbar or developer-mode response. 6. **Confirm the website connection.** Load the public page once, return to Installation, and confirm Script connected before enabling scheduled operations or approved visitor mappings. #### Drupal 10 and 11 Define an external script in the active theme's libraries.yml with async and data-site-key attributes, then attach that library globally from the theme info file or a site-owned module. Replace the example namespace and key with your real values. **your_theme.libraries.yml** ~~~text docaccessible: js: https://docaccessible.com/site/v1.js: type: external attributes: async: true data-site-key: YOUR_SITE_KEY ~~~ **your_theme.info.yml global library** ~~~text libraries: - your_theme/docaccessible ~~~ #### Joomla 4 and 5 Register and use the external script through the Web Asset Manager from the active template or a site-owned extension. Keep the custom site-key attribute on the final script element. **Active template or extension example** ~~~text $wa = $this->getWebAssetManager(); $wa->registerAndUseScript( 'docaccessible.site', 'https://docaccessible.com/site/v1.js', [], ['async' => true, 'data-site-key' => 'YOUR_SITE_KEY'] ); ~~~ #### CMS cache and aggregation checks Asset aggregation can alter loading order, but it must not remove the data-site-key attribute or replace the external URL with a client-only loader. Verify the final anonymous HTML after every optimization change. - Clear CMS render and asset caches. - Purge reverse-proxy and CDN HTML caches. - Confirm the script is attached to the public theme, not only an admin theme. - Check multisite or multilingual domains individually when they use different hosts. #### Official CMS references Use the official asset APIs for maintainable theme and extension changes. Exact namespaces and deployment conventions remain specific to your site. - [Drupal: Add assets through libraries.yml](https://www.drupal.org/docs/develop/theming-drupal/adding-assets-css-js-to-a-drupal-theme-via-librariesyml): Define JavaScript assets and attach a theme library globally. - [Joomla: Web Asset Manager](https://manual.joomla.org/docs/next/general-concepts/web-asset-manager/): Register, configure, and enable JavaScript assets through Joomla's supported API. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Install the website script on a custom-built site](https://docaccessible.com/docs/install-script-custom-sites) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) ### Install the website script on a custom-built site Canonical URL: https://docaccessible.com/docs/install-script-custom-sites Add the generated tag to static HTML, shared server templates, React or Vite entry HTML, or a Next.js root layout without breaking verification. - Category: Website monitoring - Audience: Frontend developers, platform engineers, and web agencies - Estimated time: 15-30 minutes plus deployment #### Prerequisites - Repository and deployment access for the public website - Knowledge of the shared layout or HTML entry point - The exact generated installation code for the connected production host #### Procedure 1. **Find the shared server-rendered entry point.** Locate the HTML file, root layout, base template, or theme that produces every public page. Verification must see the tag in the returned HTML source. 2. **Copy the exact generated tag.** Use the Installation tab for the connected domain. Do not hard-code a key copied from development, staging, or another tenant. 3. **Add the tag once near the end of body.** Place a native script element in the shared layout immediately before the closing body tag. Do not use a framework helper that inserts the final tag only after hydration. 4. **Update Content Security Policy.** Allow the exact DocAccessible origin in script-src, connect-src, and img-src when the site uses a restrictive policy. Preserve all existing directives. 5. **Deploy and inspect production source.** Deploy through the normal pipeline, open a public production page, and verify the key in View page source rather than only in the hydrated DOM. 6. **Trigger and confirm verification.** Reload that public page once, return to Installation, and confirm the script is connected. Add this source check to future layout and domain migrations. #### Static HTML and server templates For a static site, place the generated tag in the shared HTML shell. For Django, Rails, Laravel, ASP.NET, Java, PHP, or another server framework, place it in the base layout used by anonymous public pages. **Shared HTML or base-template placement** ~~~text
~~~ #### Next.js App Router Add a native asynchronous script element to the root app/layout.tsx so the exact tag appears in the server response for every route. Do not use next/script with afterInteractive or lazyOnload for this installation because those strategies create the final script after hydration and the verification fetch does not execute application JavaScript. **app/layout.tsx** ~~~text export default function RootLayout({ children }) { return ( {children} ); } ~~~ #### React, Vite, and other single-page applications Put the generated tag in the built application's index.html, not inside useEffect or a route component. The script observes dynamically inserted PDF links, while keeping the tag in entry HTML allows the verification fetch to prove installation. **index.html** ~~~text
~~~ #### Development, staging, and production Treat each public host as a separate installation boundary. Use the production website's generated key only on its connected host, and do not expose a production key in preview deployments that use unrelated domains. - Keep the script URL and key in deployment configuration when environments differ. - Render the complete tag on the server rather than constructing it after hydration. - Verify redirects do not move the reporting page to a different host. - Recheck source after changing the root layout, CDN, reverse proxy, or primary domain. #### Official framework reference For Next.js, the root layout is the shared application boundary that defines the document body for every route. - [Next.js: Root layout](https://nextjs.org/docs/app/api-reference/file-conventions/layout): Use the top-level app layout as the shared HTML and body boundary. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Tag managers and client-only script installation](https://docaccessible.com/docs/script-installation-tag-managers) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) ### Tag managers and client-only script installation Canonical URL: https://docaccessible.com/docs/script-installation-tag-managers Understand why Google Tag Manager and runtime-only injection cannot complete secure website verification, and move the tag to a supported global template. - Category: Website monitoring - Audience: Analytics teams, web governance owners, and frontend developers - Estimated time: 10 minutes plus the supported installation change #### Prerequisites - The generated DocAccessible installation code - Access to identify how the current tag is injected - A web owner who can change the CMS, theme, or server-rendered layout #### Procedure 1. **Confirm whether the tag is runtime-only.** Open View page source and search for data-site-key. If it appears only in the Elements panel after Google Tag Manager, useEffect, or another loader runs, the installation cannot prove domain control. 2. **Choose the platform's server-rendered method.** Use the CMS global Footer or Body - end field, active theme, asset manager, static index.html, or shared server layout instead. 3. **Paste the exact generated tag.** Copy the code from DocAccessible Installation and publish it once through that supported method. Do not wrap it in another client-side tag loader. 4. **Remove the duplicate runtime tag.** After the new source-visible installation is live, disable the Google Tag Manager or component-injected copy so each page runs only one instance. 5. **Verify source and connection.** Open a public page, confirm the key in its original source, reload once, and return to DocAccessible for Script connected status. #### Why runtime-only injection fails verification A tag manager executes after a browser loads the page. DocAccessible deliberately performs a separate server-side fetch of the reported URL and requires the exact script tag and key in that returned HTML. This prevents a browser Origin header or an injected request from being treated as ownership proof. The browser may send a discovery report from a runtime tag, but the website remains unverified and protected operations stay unavailable. #### Supported replacements Choose the installation route that owns the public source. The tag can remain asynchronous and does not need to block rendering. - [WordPress](https://docaccessible.com/docs/install-script-wordpress): Use a site-wide code tool or a child-theme hook without editing the parent theme. - [Shopify](https://docaccessible.com/docs/install-script-shopify): Add the generated tag to theme.liquid and keep the change with the active theme. - [Webflow](https://docaccessible.com/docs/install-script-webflow): Use site-level Footer code, publish the site, and verify the custom domain. - [Wix](https://docaccessible.com/docs/install-script-wix): Add custom code to every page at Body - end and confirm it survives publication. - [Squarespace](https://docaccessible.com/docs/install-script-squarespace): Use site-wide Footer code injection on an eligible plan. - [Drupal or Joomla](https://docaccessible.com/docs/install-script-drupal-joomla): Install through the active theme or the CMS asset manager and clear caches. - [Custom HTML, React, Next.js, and server frameworks](https://docaccessible.com/docs/install-script-custom-sites): Place the script in the shared server-rendered layout so it appears in page source. #### When policy allows only a tag manager Ask the web platform owner to approve one source-visible global script with the documented service origin and site key. If governance cannot permit a server-rendered installation, secure website verification cannot complete and website monitoring should remain disconnected rather than weakening ownership checks. - Share the exact generated tag and the data-collected explanation from Installation. - Document script-src, connect-src, and img-src requirements for security review. - Confirm that the script does not collect cookies, form values, visitor identity, or full page content. - Keep the approved installation in the site's release and change-management record. #### Official Google Tag Manager reference Google documents custom tags as browser-executed container behavior. That remains useful for analytics workflows, but it does not change DocAccessible's source-visible ownership requirement. - [Google Tag Manager custom templates](https://developers.google.com/tag-platform/tag-manager/templates): Review how custom tags execute through a published Tag Manager container. #### Related documentation - [Install the website monitoring script](https://docaccessible.com/docs/install-website-script) - [Install the website script on a custom-built site](https://docaccessible.com/docs/install-script-custom-sites) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) ### Review website PDF inventory and source changes Canonical URL: https://docaccessible.com/docs/website-pdf-inventory Prioritize discovered PDFs, read scan history, handle plan limits, and respond when a public source changes. - Category: Website monitoring - Audience: Website accessibility owners and content operators - Estimated time: 5 minutes per review session #### Prerequisites - A verified website connection with discovered PDF links #### Procedure 1. **Open the monitoring inbox.** Review PDFs across all connected websites, then filter by source changes, failed checks, manual-review findings, website, or assignee. 2. **Prioritize active PDFs.** Plan-eligible discoveries receive active scan slots. Over-limit records remain visible but are not fetched until capacity is available. 3. **Assign and triage bounded work.** Select PDFs to assign an owner, acknowledge, snooze, ignore, restore, or queue another check. Conversion and publication are intentionally excluded from bulk actions. 4. **Compare scan evidence.** Open History on a PDF and compare two immutable checks to see score movement plus new, persistent, and resolved automated findings. 5. **Respond to alerts and source changes.** A changed content hash means the public PDF is different. Assign or acknowledge the alert, then recheck the source and any published alternative before treating the mapping as current. #### How capacity works Website domain and PDF allowances are separate from remediation uploads. If capacity changes, the oldest included domains and PDFs remain active first while excess inventory stays visible and paused. #### Safe remote fetching The worker revalidates redirects, enforces response bounds, validates the PDF signature, scans for malware, and runs automated inspection in a bounded process. #### Monitoring policies and alerts Each website can use a plan-bounded check interval, script-silence window, allowance threshold, and alert recipients. Alerts can be assigned, acknowledged, snoozed, or resolved without automatically converting or republishing content. #### Portfolio evidence export The monitoring inbox exports current automated evidence as CSV for operational reporting. The export states that manual review is still required and must not be presented as a conformance certificate. #### Related documentation - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Convert a discovered PDF and publish an accessible alternative](https://docaccessible.com/docs/publish-website-alternatives) - [Understand automation, conformance, and manual remediation](https://docaccessible.com/docs/accessibility-boundaries) ### Convert a discovered PDF and publish an accessible alternative Canonical URL: https://docaccessible.com/docs/publish-website-alternatives Create a private remediation draft from a public PDF, review it, and explicitly map one completed version for website visitors. - Category: Website monitoring - Audience: Website owners, publishers, and accessibility reviewers - Estimated time: Varies by document #### Prerequisites - A discovered PDF on a verified website - Remediation allowance when converting into a private document #### Procedure 1. **Choose Convert to private draft.** Conversion imports the selected public PDF into the normal private document workflow. It does not replace the public link or publish output automatically. 2. **Review and edit the output.** Resolve machine-detectable issues and manual-review items, then validate the intended reader experience. A rebuilt PDF may not preserve the source layout. 3. **Select the exact completed version.** Choose the version that should serve as the accessible alternative. Approval status is shown when a reviewer approved that exact version. 4. **Confirm and publish the mapping.** Confirm source ownership and the human-review boundary. Only then can the optional viewer replace mapped links at runtime. 5. **Monitor the source afterward.** If the source PDF changes, review the change and update or disable the mapping. The original PDF remains available from the viewer. #### Viewer behavior The viewer presents approved semantic HTML in a keyboard-accessible dialog, includes an original-PDF link, and states the output limitation. A site-level switch can disable all mappings immediately. #### No automatic compliance claim Detection, conversion, and publication are separate actions. Installing the script does not make every PDF accessible and does not certify the source website or documents. #### Related documentation - [Review website PDF inventory and source changes](https://docaccessible.com/docs/website-pdf-inventory) - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) - [Publish and share accessible output](https://docaccessible.com/docs/publish-and-share) ### Create and manage an Exchange case Canonical URL: https://docaccessible.com/docs/exchange-cases Set acceptance criteria, invite a scoped vendor, and keep source files, deadlines, and activity in one controlled case. - Category: Exchange - Audience: Document owners, vendor managers, and workspace operators - Estimated time: 10 minutes to create #### Prerequisites - Available active Exchange case capacity - A source document and a clear owner for the final decision #### Procedure 1. **Choose a playbook or create a case.** Start with the standard checklist or a workspace playbook. A playbook copies instructions and acceptance criteria into independent case rows without sharing evidence or vendor access. 2. **Create one case or import a CSV.** For portfolio work, import up to 100 draft cases with a title column and optional priority, deadlines, assignments, and playbook. Capacity is checked atomically before any rows are created. 3. **Assign ownership and milestones.** Choose a case manager and reviewer, then set ordered vendor, QA, delivery, and final case deadlines so each stage has an accountable owner. 4. **Invite the vendor and track activity.** Send the case-scoped invitation and use the timeline, comments, evidence, milestones, and status transitions rather than moving files through untracked email threads. #### Case lifecycle The normal path moves from draft through assignment, vendor work, submission, QA review, approval, controlled delivery, and archive. Requested changes create a resubmission path instead of overwriting the prior revision. #### Vendor access Vendor and recipient links are scoped, expiring where applicable, and stored as hashes. Do not forward a vendor link to another person or use one case as a general shared drive. #### Playbooks and safe cloning Playbooks are workspace-owned setup templates. Editing a playbook never changes criteria already copied into a case. Cloning creates a new draft with open criteria; source and reference files are copied only when explicitly requested. #### Revision intelligence The case workspace can compare immutable file hashes, size, page count, selected PDF structure facts, and acceptance evidence activity. These differences help focus review but do not certify WCAG, PDF/UA, ADA, or legal conformance. #### Related documentation - [Review, approve, and deliver Exchange work](https://docaccessible.com/docs/exchange-review-and-delivery) - [Manage workspaces, members, invitations, and roles](https://docaccessible.com/docs/members-workspaces-and-roles) - [Understand plans, billing, and usage limits](https://docaccessible.com/docs/plans-billing-and-usage) ### Review, approve, and deliver Exchange work Canonical URL: https://docaccessible.com/docs/exchange-review-and-delivery Compare immutable revisions, verify evidence, request changes, approve the right submission, and create controlled delivery access. - Category: Exchange - Audience: Case owners and accessibility reviewers - Estimated time: Varies by case #### Prerequisites - An Exchange case with a vendor submission or pending action #### Procedure 1. **Open the action inbox.** Start with overdue cases, inactive vendors, submitted revisions awaiting review, and requested resubmissions. 2. **Review the returned revision.** Compare the current immutable revision with the source and evaluate every acceptance criterion and attached evidence. 3. **Approve or request changes.** Record a specific decision. Requested changes preserve the submitted revision and require a new resubmission rather than replacement in place. 4. **Create controlled delivery.** After approval, create a recipient link with the intended expiry and download allowance. Archive only after delivery obligations are complete. #### Evidence and approval The review workspace helps organize comparison and evidence. It does not certify the returned file. Preserve the criteria, checks, reviewer decision, and exact revision in the case record. #### Notifications and summaries Milestone notifications and daily summaries are designed to highlight meaningful actions rather than email every minor event. Users can manage supported notification preferences in settings. #### Related documentation - [Create and manage an Exchange case](https://docaccessible.com/docs/exchange-cases) - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) - [Use API keys and signed webhooks](https://docaccessible.com/docs/api-keys-and-webhooks) ### Collect and resolve reader accessibility feedback Canonical URL: https://docaccessible.com/docs/accessibility-feedback Use hosted-document feedback to reproduce barriers, assign ownership, record resolution, and close the loop with readers. - Category: Collaboration - Audience: Accessibility owners and support teams - Estimated time: 5 minutes per report #### Prerequisites - An eligible plan - A hosted document where reader feedback is available #### Procedure 1. **Triage new reports.** Open Accessibility feedback and review the reported barrier, location, browser or assistive technology, contact preference, and linked document. 2. **Assign an owner.** Move the report to In review and assign an eligible workspace member so responsibility is explicit. 3. **Reproduce and fix.** Use the reported context to reproduce the barrier, update the source or accessible version, and run appropriate manual validation. 4. **Record resolution.** Add an internal note with reproduction details, changes, validation, and follow-up. Mark resolved only when the response is complete. #### Contacting the reader Contact details are shown only when the reporter provided them and consented to follow-up. Keep private notes factual and do not expose internal notes on the public document. #### Feedback is not a legal complaint channel The feedback workflow records product accessibility barriers and operational follow-up. It does not replace a formal legal, civil-rights, privacy, or records-request process. #### Related documentation - [Publish and share accessible output](https://docaccessible.com/docs/publish-and-share) - [Manage workspaces, members, invitations, and roles](https://docaccessible.com/docs/members-workspaces-and-roles) - [Get support and report an accessibility barrier](https://docaccessible.com/docs/contact-support) ### Manage workspaces, members, invitations, and roles Canonical URL: https://docaccessible.com/docs/members-workspaces-and-roles Keep work in the right workspace, invite teammates, assign least-privilege roles, and transfer ownership carefully. - Category: Account and operations - Audience: Workspace owners and admins - Estimated time: 10 minutes #### Prerequisites - Owner or admin permissions for the active workspace #### Procedure 1. **Confirm the active workspace.** Use the header switcher before inviting members or changing settings. Customer workspace selection never changes platform-admin scope. 2. **Invite by email.** Choose a role that matches the person's responsibilities. Seat and workspace limits are enforced by the active plan. 3. **Review pending invitations.** Cancel invitations that are no longer required and resend only when appropriate. Invitation access should not be forwarded. 4. **Change roles or ownership.** Use least privilege. Ownership transfer is a high-impact action and should be confirmed with the receiving owner before completion. #### Role expectations Owners control the workspace and high-impact settings. Admins manage operations. Contributors perform assigned work. Viewers receive read-focused access. The API rechecks every protected action regardless of what the UI displays. #### Keep workspace data separated Documents, sites, feedback, reviews, keys, and Exchange cases belong to the active workspace. Verify the switcher after changing organizations or testing multiple accounts. #### Related documentation - [Get started with DocAccessible](https://docaccessible.com/docs/getting-started) - [Use API keys and signed webhooks](https://docaccessible.com/docs/api-keys-and-webhooks) - [Understand plans, billing, and usage limits](https://docaccessible.com/docs/plans-billing-and-usage) ### Manage account access, security, export, and deletion Canonical URL: https://docaccessible.com/docs/account-security-and-data Verify account access, recover or change a password, export your documents, and understand permanent account deletion. - Category: Account and operations - Audience: All account holders - Estimated time: 5 minutes #### Prerequisites - A signed-in account for settings and export actions #### Procedure 1. **Use the available account path.** Public account creation may be open, waitlisted, or paused. In waitlist mode, submit the request form and use the time-limited invitation sent to the same email address. A valid workspace invitation remains an account path in every mode. 2. **Verify a new email address.** Open the verification link sent after signup. Verification links expire and are intended for the addressed account; request a fresh message if the link no longer works. 3. **Recover access when needed.** Choose Forgot password on the sign-in page, submit the account email, and use the time-limited reset link. The response does not reveal whether an email is registered. 4. **Change a known password.** In Account and integrations, enter the current password and a new strong password. Sign out of shared devices when the change is complete. 5. **Export your documents.** Use Export all documents to create an authorized archive of account document data. Protect the downloaded archive according to your organization's retention and privacy rules. 6. **Delete only after reviewing the impact.** Account deletion is permanent and removes owned documents, versions, share links, API keys, sessions, and subscription data. Transfer required workspace responsibilities and retain authorized records first. #### Credential and session safety Use a unique password stored in a password manager. Do not send reset links, passwords, API keys, or webhook secrets through tickets or document comments. Use Sign out from the account menu when a session should end. A public page may still show your account state until the sign-out request completes and navigation refreshes. #### The deletion boundary Deletion is an account-level operation, not a way to remove one document. Use document controls for individual records and workspace member controls for access changes. Do not start deletion while paid billing, evidence retention, or workspace ownership still needs attention. Contact support before deleting when the correct ownership path is unclear. #### Related documentation - [Manage workspaces, members, invitations, and roles](https://docaccessible.com/docs/members-workspaces-and-roles) - [Use API keys and signed webhooks](https://docaccessible.com/docs/api-keys-and-webhooks) - [Get support and report an accessibility barrier](https://docaccessible.com/docs/contact-support) ### Use API keys and signed webhooks Canonical URL: https://docaccessible.com/docs/api-keys-and-webhooks Create scoped integration credentials, verify signed webhook deliveries, and operate integrations without exposing secrets. - Category: Account and operations - Audience: Workspace owners, admins, and integration developers - Estimated time: 15 minutes #### Prerequisites - An eligible plan and workspace role - A secure secret manager for credentials #### Procedure 1. **Create a named API key.** Use a purpose-specific name. Copy the plaintext value immediately and store it in a secret manager; the full value is not shown again. 2. **Configure a webhook endpoint.** Use HTTPS in production, select only required events, and store the signing secret securely. 3. **Verify every delivery.** Validate the timestamped HMAC signature against the raw request body, enforce the allowed time window, and reject mismatches before parsing or acting. 4. **Test, observe, and rotate.** Send a test event, inspect delivery status, rotate exposed secrets, and revoke unused keys. Do not place credentials in browser code or logs. #### Delivery safety Webhook retries can repeat an event, so consumers should be idempotent. Treat payloads as workspace data and avoid logging document content, private URLs, tokens, or credentials. #### Related documentation - [Manage workspaces, members, invitations, and roles](https://docaccessible.com/docs/members-workspaces-and-roles) - [Manage account access, security, export, and deletion](https://docaccessible.com/docs/account-security-and-data) - [Review, approve, and deliver Exchange work](https://docaccessible.com/docs/exchange-review-and-delivery) - [Get support and report an accessibility barrier](https://docaccessible.com/docs/contact-support) ### Understand plans, billing, and usage limits Canonical URL: https://docaccessible.com/docs/plans-billing-and-usage Read workspace allowances, choose a plan, start checkout, and understand which limits apply to each workflow. - Category: Account and operations - Audience: Workspace owners and purchasers - Estimated time: 5 minutes #### Prerequisites - Workspace owner access for billing changes #### Procedure 1. **Review current usage.** The dashboard and billing page show the active workspace plan and relevant document, website, member, workspace, and Exchange allowances. 2. **Compare the complete contract.** Use the Pricing page for current published limits. Exchange is an operations-focused plan and does not include automated document remediation. 3. **Start checkout as the signed-in owner.** Choose the intended plan from Pricing or Billing. The server maps the checkout product to a known plan; unknown products do not grant access. 4. **Confirm the resulting plan.** After payment completes, return to Billing and verify the active plan before relying on new capacity. Complimentary access granted by a platform administrator is labeled separately, includes its scheduled end when one exists, and does not represent a charge or a payment-provider subscription. #### Limits are enforced separately Document remediation, upload size, members, workspaces, active Exchange cases, monitored domains, and monitored PDFs are distinct allowances. Website scanning does not consume a remediation upload until you explicitly convert a discovered PDF. #### Billing support For a payment, invoice, or plan-sync problem, contact support with the workspace name and approximate transaction time. Do not send card details or secret keys. #### Related documentation - [Get started with DocAccessible](https://docaccessible.com/docs/getting-started) - [Set up an organization document portal](https://docaccessible.com/docs/organization-portals) - [Connect a website and install PDF monitoring](https://docaccessible.com/docs/website-monitoring-setup) - [Create and manage an Exchange case](https://docaccessible.com/docs/exchange-cases) ### Run an accessibility program hub Canonical URL: https://docaccessible.com/docs/program-hub Collect client requests, choose a defensible remediation path, coordinate work across workspaces, and record version-bound release evidence. - Category: Collaboration - Audience: Agencies, accessibility leads, and client service teams - Estimated time: 12 minutes #### Prerequisites - A workspace owner, admin, or editor account - A clear internal owner for client intake and release decisions #### Procedure 1. **Create the private intake link.** Open Program and create the current workspace's client intake link. The complete bearer link is shown once, so send it through an appropriate private channel. Rotating it immediately revokes the previous intake link. 2. **Review the request and routing recommendation.** Open each request from the queue. Confirm the requested outcome, service impact, source constraints, and the reasons behind the suggested HTML-first, automation-plus-review, or specialist-PDF path. 3. **Assign and record the decision.** Choose a workspace owner, status, priority, and delivery path. A decision note is required when the team overrides the automated recommendation so the reason remains in the request record. 4. **Complete the version-bound release record.** On the linked document, record the human checks, assistive technology and tasks, exceptions, and release outcome for the exact current version. A linked request cannot be marked ready for the client or completed until that version is ready or ready with documented exceptions. Download the evidence record for the client or project file. #### Clients can submit without joining the workspace The intake page accepts one PDF, DOCX, or public source URL. A successful submission creates a private request-specific status link; it does not create an account, workspace membership, or access to other client work. Intake and status tokens are stored as hashes. Treat the links as bearer credentials: share them privately, rotate intake if it leaks, and rotate an exposed status link from the request detail page. #### Use triage to prioritize, not certify HTML-first is appropriate when responsive content is the primary reading experience and no specialist constraint is visible. Automation plus review is the working path for source uncertainty, tables, images, unresolved findings, or service-critical content. Exact layout, unreliable scans, forms, maps, equations, signatures, and complex tables should move to a qualified PDF specialist. A confidence percentage describes the strength of the routing signal. It is not a conformance score, legal opinion, or promise that the resulting document is accessible. #### What the release record proves The downloadable record identifies the exact source and output fingerprints, automated findings, selected remediation path, recorded human checklist, assistive-technology notes, review state, and open reader feedback for one immutable version. Every required check must be passed or marked not applicable before a version can be recorded as ready. A ready-with-exceptions outcome also requires a complete checklist and written exception notes. Creating a newer document version makes the earlier record historical and restores the release gate. It proves what the team recorded and which version it reviewed. It does not independently certify WCAG, PDF/UA, ADA, or Section 508 conformance. #### Operate across client workspaces The portfolio summarizes open requests, overdue work, documents needing attention, website alerts, and Exchange actions across every workspace you belong to. Open a workspace from the portfolio before changing its request queue or intake settings. #### Related documentation - [Understand automation, conformance, and manual remediation](https://docaccessible.com/docs/accessibility-boundaries) - [Set up an organization document portal](https://docaccessible.com/docs/organization-portals) - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) - [Collect and resolve reader accessibility feedback](https://docaccessible.com/docs/accessibility-feedback) ### Set up an organization document portal Canonical URL: https://docaccessible.com/docs/organization-portals Reserve a managed organization hostname, invite your team, configure the public directory, and publish reviewed document versions safely. - Category: Collaboration - Audience: Organization workspace owners and administrators - Estimated time: 15 minutes plus document review #### Prerequisites - An active Organization plan - Workspace owner or administrator access - An agreed managed subdomain name that your organization is prepared to keep - A release-ready document version with completed human review evidence before publication #### Procedure 1. **Check and reserve the managed hostname.** Open Organization settings, enter the intended subdomain, and check availability before confirming the claim. A workspace can have one active managed hostname. Retired hostnames remain permanent tombstones and are not reassigned, so review the spelling and ownership decision carefully. 2. **Configure the portal identity.** Set the display name, description, and accent color. Choose whether the public document directory is enabled and whether search engines may index it. These choices affect public presentation, not access to private workspace records. 3. **Invite the organization team.** Send workspace invitations from the tenant hostname and assign the minimum role each person needs. Signed-in document, website, Program, review, job, feedback, and Exchange work stays locked to the hostname's workspace. 4. **Prepare the exact document version.** Complete automated checks and the required human release evidence against the version intended for the portal. A score or internal approval alone does not certify accessibility or bypass the release-readiness gate. 5. **Publish and verify the public route.** Choose a unique portal path, create the publication, and open the public page from the tenant hostname. Confirm the title, language, accessible HTML, approved downloads, feedback option, and version number before distributing the URL. 6. **Republish or withdraw deliberately.** Later workspace edits do not replace the public version. Review the newer immutable version and explicitly republish when it is ready, or withdraw the publication immediately when public access should end. #### The managed hostname runs the complete workspace The organization hostname is not a limited document microsite. It uses the same entitled DocAccessible application for documents, reviews, Program Management, website monitoring, feedback, jobs, Exchange cases, billing, API keys, and webhooks. Team invitations, Exchange vendor and delivery routes, milestone and digest messages, job notifications, and monitoring alerts use the active tenant hostname. External Exchange participants remain case-scoped and do not become workspace members. #### How tenant isolation works The tenant hostname selects the workspace before an authenticated request reaches application data. The workspace cookie cannot switch a tenant request into another workspace, and the API rejects missing or conflicting tenant context even when a person belongs to both organizations. This is a host-scoped multi-tenant application. The Organization plan does not promise a customer-owned domain, separate deployment, separate database, or separate storage bucket. #### Control publication and search visibility separately Workspace content stays private by default. Public access requires a separate publication record bound to one immutable document version. The public directory can be disabled while already shared publication links remain controlled by their individual records. Search indexing is an administrator choice. When indexing is enabled, the portal exposes host-specific canonical metadata, structured data, robots guidance, and a sitemap containing listed publications. Keep indexing disabled for private, sensitive, test, or unlisted material. #### Downgrade, withdrawal, and hostname retirement After a downgrade, existing tenant pages remain readable, but the workspace cannot claim another name, change branding, or create new publications. Administrators can still withdraw a publication or retire the hostname as an emergency revocation action. Retirement is not a rename shortcut. A retired hostname cannot be assigned to another workspace. Reserve a replacement only after the organization has evaluated link migration, communications, search impact, and the permanent loss of the old name. #### Review the feature contract before purchase The feature overview explains the managed-hostname model, included workflows, publication boundary, and current limitations. The Pricing page remains the source for current Organization allowances and subscription price. - [Organization document portals](https://docaccessible.com/features/organization-document-portals): Review the complete feature, security, publication, and scope overview. - [Plans and pricing](https://docaccessible.com/pricing): Confirm the current Organization plan price and enforced allowances. #### Related documentation - [Run an accessibility program hub](https://docaccessible.com/docs/program-hub) - [Manage workspaces, members, invitations, and roles](https://docaccessible.com/docs/members-workspaces-and-roles) - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) - [Create and manage an Exchange case](https://docaccessible.com/docs/exchange-cases) - [Collect and resolve reader accessibility feedback](https://docaccessible.com/docs/accessibility-feedback) ### Use the free PDF accessibility checker Canonical URL: https://docaccessible.com/docs/free-pdf-checker Run a bounded structural inspection, interpret passed, failed, and manual-review findings, and decide the next remediation step. - Category: Start here - Audience: Anyone evaluating a PDF - Estimated time: 2-5 minutes #### Prerequisites - A PDF you are permitted to upload #### Procedure 1. **Upload the PDF.** The server validates the file and applies structural rules. When available, pinned veraPDF validation provides an independent machine signal. 2. **Read findings by status.** Passed means the available machine evidence supports the check. Failed means a detectable issue was found. Needs review means a person must decide. 3. **Use the result to plan work.** Prioritize blocking structural issues, then schedule manual review for content and behavior that automation cannot verify. 4. **Choose a remediation path.** Use DocAccessible for editable HTML and rebuilt PDF output when reflow is acceptable, or request qualified manual remediation when the original layout must be preserved. #### What the checker does not prove A checker result is not certification. It cannot fully determine reading experience, visual meaning, complex tables, forms, or whether alternative text fits the document's purpose. #### Related documentation - [Understand automation, conformance, and manual remediation](https://docaccessible.com/docs/accessibility-boundaries) - [Upload and remediate a document](https://docaccessible.com/docs/upload-and-remediate) - [Get support and report an accessibility barrier](https://docaccessible.com/docs/contact-support) ### Understand automation, conformance, and manual remediation Canonical URL: https://docaccessible.com/docs/accessibility-boundaries Know what DocAccessible automates, what still requires human validation, and when exact-layout manual PDF remediation is the right path. - Category: Start here - Audience: Accessibility leads, publishers, reviewers, and purchasers - Estimated time: 8 minutes #### Prerequisites - None beyond access to the public documentation. #### Procedure 1. **Define the required output.** Decide whether readers need responsive web content, an offline tagged PDF, the exact original layout, or more than one format. 2. **Use automation for detectable structure.** Automated checks and remediation can help with tags, headings, lists, language, links, images, and normalized content where evidence is sufficient. 3. **Keep manual decisions open.** Use qualified review for reading order, complex tables, charts, forms, contextual alternatives, language changes, and assistive-technology behavior. 4. **Choose manual remediation for exact layout.** If design, pagination, forms, or print behavior must remain unchanged, use a qualified human remediation path instead of relying on a rebuilt PDF. DocAccessible agency work is available for projects above 500 pages at $5 per accepted source page. #### Responsible claims Do not describe a score, automated check, rebuilt output, or workflow approval as proof of WCAG, PDF/UA, ADA, or Section 508 conformance. Record the evidence and human decisions that support your own release process. #### Build a validation plan Match review depth to audience, document complexity, legal obligations, and the consequences of failure. Include keyboard and screen-reader checks with representative tasks, not only validator output. #### Related documentation - [Use the free PDF accessibility checker](https://docaccessible.com/docs/free-pdf-checker) - [Review findings and edit accessible content](https://docaccessible.com/docs/review-findings-and-edit) - [Request review and approve an exact version](https://docaccessible.com/docs/review-and-approval) ### Get support and report an accessibility barrier Canonical URL: https://docaccessible.com/docs/contact-support Send enough context for a useful response without putting confidential documents or sensitive credentials into the contact form. - Category: Account and operations - Audience: All users and readers - Estimated time: 3 minutes #### Prerequisites - None beyond access to the public documentation. #### Procedure 1. **Choose the right request type.** Select product support, document remediation, Exchange, billing, privacy, partnership, or accessibility barrier so the request reaches the right workflow. 2. **Describe the outcome and context.** Include the workspace or public page, what you expected, what happened, timing, and relevant browser or assistive technology. 3. **Keep sensitive material out of the form.** Do not paste passwords, API keys, payment details, private share links, or confidential document content. Support will arrange a secure transfer route when a file is required. 4. **Prioritize active accessibility barriers.** For a barrier blocking access to content or a task, include the page URL, device, browser, assistive technology, and the step that could not be completed. #### What happens next A person reviews the private request and chooses the correct response path. Urgent accessibility barriers are prioritized; project timing depends on scope and required evidence. #### Related documentation - [Monitor processing jobs and retry failures](https://docaccessible.com/docs/processing-jobs-and-retries) - [Collect and resolve reader accessibility feedback](https://docaccessible.com/docs/accessibility-feedback) - [Understand plans, billing, and usage limits](https://docaccessible.com/docs/plans-billing-and-usage) ## Product comparisons ### DocAccessible vs Adobe Acrobat for PDF accessibility Canonical URL: https://docaccessible.com/compare/adobe-acrobat Reviewed: July 14, 2026 Acrobat gives a skilled operator direct control over the original PDF. DocAccessible starts with a browser workflow that checks a document, creates accessible web content and a rebuilt tagged PDF, then carries the result through review, sharing, monitoring, or vendor handoff. - Consider Adobe Acrobat: Choose Acrobat when a trained remediator needs direct access to the original tag tree, page objects, forms, reading order, and exact PDF presentation. - Consider DocAccessible: Choose DocAccessible when the job includes accessible web publishing, a reviewable automated first pass, version history, approvals, website inventory, or secure external handoff. Sources: - [Adobe: Create and verify PDF accessibility](https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html) - [Adobe: Creating accessible PDFs](https://helpx.adobe.com/acrobat/using/creating-accessible-pdfs.html) ### DocAccessible vs Equidox: PDF remediation compared Canonical URL: https://docaccessible.com/compare/equidox Reviewed: July 14, 2026 Both products use browser-based workflows to reduce difficult PDF accessibility work. Equidox centers on hands-on PDF remediation with detection tools for document elements. DocAccessible combines an automated first pass with hosted HTML, rebuilt PDF output, public delivery, website monitoring, approvals, and vendor operations. - Consider Equidox: Choose Equidox when your team wants a specialist remediation environment with zone detection, table and list tools, form support, and the option of SaaS or on-premises deployment. - Consider DocAccessible: Choose DocAccessible when the larger problem is getting from website inventory or upload to a reviewed, published, monitored result through one self-service workflow. Sources: - [Equidox: PDF accessibility software](https://equidox.co/pdf-solutions/pdf-accessibility-software/) - [Equidox: PDF accessibility solutions](https://equidox.co/) ### DocAccessible vs Allyant CommonLook PDF remediation Canonical URL: https://docaccessible.com/compare/commonlook Reviewed: July 14, 2026 CommonLook PDF is a long-established specialist remediation product with simplified and advanced editing paths, browser and desktop access, and standards-oriented validation. DocAccessible is lighter-weight and broader: it automates a first output, publishes accessible HTML, and manages the review and delivery work around the document. - Consider Allyant CommonLook PDF: Choose CommonLook PDF when specialists need simplified and advanced editing, direct PDF remediation, detailed validation, and a mature enterprise document-accessibility suite. - Consider DocAccessible: Choose DocAccessible when teams need a quick self-service path from upload or website discovery to hosted HTML, rebuilt PDF, approval, feedback, or secure vendor delivery. Sources: - [Allyant: CommonLook PDF remediation software](https://allyant.com/pdf-accessibility-software-solutions/commonlook-pdf/) - [Allyant: CommonLook PDF simplified editor guide](https://support.allyant.com/support/solutions/articles/156000367421-web-based-commonlook-pdf-simplified-editor-quick-start-guide) ### DocAccessible vs Grackle PDF accessibility tools Canonical URL: https://docaccessible.com/compare/grackle-pdf Reviewed: July 14, 2026 Grackle PDF is a Windows desktop remediation and validation environment for people working directly on accessible PDFs. DocAccessible is a hosted workflow for checking, automated transformation, accessible web publication, rebuilt PDF output, review, monitoring, and external handoff. - Consider Grackle PDF: Choose Grackle PDF when Windows-based remediators need guided tag repair, specialized table and image tools, and built-in Matterhorn Protocol validation without Acrobat. - Consider DocAccessible: Choose DocAccessible when browser access, hosted accessible HTML, team operations, website inventory, and secure customer-vendor workflows matter more than deep desktop PDF editing. Sources: - [GrackleDocs: Grackle PDF remediation software](https://www.grackledocs.com/en/products-services/grackle-pdf/) - [GrackleDocs: PDF remediation services](https://www.grackledocs.com/en/products-services/pdf-remediation/) ### PDF accessibility checker comparison Canonical URL: https://docaccessible.com/compare/pdf-accessibility-checkers Reviewed: July 14, 2026 The right checker depends on whether you need a quick browser triage, a Windows visual-review tool, repair inside a PDF editor, or repeatable machine validation in a technical pipeline. No checker can make the final accessibility decision alone. - Consider PDF accessibility checkers: Choose PAC, Acrobat, or standalone veraPDF when you need their specific desktop, repair, visual-review, or command-line validation workflow. - Consider DocAccessible: Choose DocAccessible when you want an online first check that can continue into remediation, hosted HTML, rebuilt output, review, sharing, and website monitoring. Sources: - [PAC: What machine and human checks cover](https://pac.pdf-accessibility.org/en/check) - [Adobe: Acrobat accessibility checker](https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html) - [veraPDF: PDF/UA validation scope](https://docs.verapdf.org/validation/) ### DocAccessible vs DocAccess: which PDF tool fits Canonical URL: https://docaccessible.com/compare/docaccess Reviewed: July 15, 2026 Both products can find public PDFs and give visitors an accessible HTML experience through a website script. DocAccess emphasizes automatic coverage and reader services such as translation, document Q&A, and live visual assistance. DocAccessible emphasizes private remediation drafts, editable output, a rebuilt tagged PDF, review evidence, and explicit version-bound publication. - Consider DocAccess: Choose DocAccess when the priority is automatic processing for current and future public PDFs, a transcript-centered reader experience, translation, document Q&A, and live visual assistance. - Consider DocAccessible: Choose DocAccessible when each discovered PDF should enter a controlled document workflow with private drafts, editing, checking, approvals, vendor handoff, tagged-PDF output, and deliberate publication. Sources: - [DocAccess: Product overview](https://docaccess.com/) - [DocAccess: Support and helper-script setup](https://docaccess.com/support) - [DocAccess: Pricing approach](https://docaccess.com/pricing) - [DocAccess: Terms and technology limitations](https://docaccess.com/terms-of-use) ## Additional public resources - [DocAccessible product overview](https://docaccessible.com/): Product capabilities, primary workflows, output boundaries, and ways to get started. - [Product features](https://docaccessible.com/features): Document remediation, review, publishing, monitoring, feedback, and operational workflows. - [Accessibility Program Management](https://docaccessible.com/features/accessibility-program-management): Capture client requests, explain remediation routing, track work across authorized workspaces, and retain version-bound release evidence. - [Organization document portals](https://docaccessible.com/features/organization-document-portals): Reserve a managed organization subdomain, invite a host-scoped team, use every entitled workflow, and publish reviewed exact document versions. - [Website PDF monitoring](https://docaccessible.com/features/website-pdf-monitoring): Discover public PDF links, assess source files, track changes, and deliberately publish approved alternatives. - [Exchange](https://docaccessible.com/exchange): Secure, versioned document handoff among customers, vendors, and reviewers. - [Remediation options](https://docaccessible.com/remediation-options): Choose between automated output, internal review, and separately scoped exact-layout manual remediation. - [Automatic PDF tagging](https://docaccessible.com/features/pdf-auto-tagging): Add a logical tag structure to an untagged PDF in place, without redrawing pages or changing the visual layout. - [Document accessibility review](https://docaccessible.com/features/document-accessibility-review): Read automated findings, resolve structure and alternative-text issues, and save a reviewed version of a document. - [Review and approval workflows](https://docaccessible.com/features/document-approval-workflows): Route a document through named reviewers and an approval decision before any version is published. - [Remediation notifications](https://docaccessible.com/features/document-remediation-notifications): Notify owners and requesters when processing finishes, review is needed, or a published version changes. - [Accessibility feedback](https://docaccessible.com/features/accessibility-feedback): Collect barrier reports from readers of a published document and route them to the owner of that document. - [Manual PDF remediation service](https://docaccessible.com/services/pdf-accessibility-remediation): Separately scoped agency remediation at $5 per page for 501-page-plus projects, preserving the exact source layout. - [Remediation options compared](https://docaccessible.com/remediation-options): Hosted accessible HTML, a rebuilt tagged PDF, and manual exact-layout remediation compared side by side. - [Free PDF accessibility tools](https://docaccessible.com/tools): Four free browser tools: accessibility checker, tag viewer, auto-tagger, and scanned-PDF text recovery. - [Free PDF accessibility checker](https://docaccessible.com/tools/pdf-checker): Run machine-detectable structural and PDF/UA-oriented checks while retaining manual-review findings. - [Free PDF tag viewer](https://docaccessible.com/tools/pdf-tag-viewer): Read the logical tag tree of any PDF in the browser: headings, tables, figures, role maps, and per-tag assessments. - [Free PDF auto-tagger](https://docaccessible.com/tools/pdf-auto-tagger): Add a verified logical tag structure to an untagged PDF without changing how the page is drawn. - [Free scanned-PDF accessibility tool](https://docaccessible.com/tools/make-scanned-pdf-accessible): Recover the text of a scanned PDF and add a tag structure inside the original file, leaving the layout untouched. - [Live hosted-HTML example](https://docaccessible.com/d/welcome): A published accessible HTML document produced by the platform, viewable without an account. - [Before and after example](https://docaccessible.com/compare/welcome): The same document shown as the original source PDF and as the generated accessible HTML. - [Solutions by sector](https://docaccessible.com/solutions): How document accessibility work is organized differently for government, education, and healthcare teams. - [Government document accessibility](https://docaccessible.com/solutions/government): Prioritizing active public records, publishing accessible alternatives, and retaining evidence across departments. - [Education document accessibility](https://docaccessible.com/solutions/education): One repeatable route for syllabi, handbooks, forms, and board materials that reach students and families. - [Healthcare document accessibility](https://docaccessible.com/solutions/healthcare): Separating documents that can become responsive HTML from regulated fixed-layout files needing specialist repair. - [PDF-to-HTML benchmark corpus](https://docaccessible.com/benchmarks/pdf-to-html): The 50 official-source pilot candidates, source PDFs, collection evidence, route hypotheses, unreviewed HTML working conversions, deterministic markup preflights, and manual-review priorities; no conversion-accuracy score is published. - [ADA Title II document accessibility guide](https://docaccessible.com/guides/ada-title-ii-2026): Planning guidance for public entities preparing web and mobile content, including documents, for applicable deadlines. - [WCAG 2.2 Level AA guide](https://docaccessible.com/guides/wcag-2-2-aa): A practical guide to WCAG 2.2 Level AA and document accessibility review. - [How to make a PDF accessible](https://docaccessible.com/guides/make-pdf-accessible): A workflow for checking, repairing, reviewing, and publishing accessible document formats. - [PDF remediation paths](https://docaccessible.com/guides/remediation-paths): Compare automated rebuilding, specialist repair, replacement content, and removal of obsolete files. - [PDF accessibility checklist](https://docaccessible.com/guides/pdf-accessibility-checklist): A review checklist spanning structure, meaning, keyboard use, assistive technology, and release evidence. - [PDF/UA and WCAG](https://docaccessible.com/guides/pdf-ua-vs-wcag): Understand how PDF/UA machine validation and WCAG-oriented evaluation complement rather than replace one another. - [PDF-to-HTML conversion quality methodology](https://docaccessible.com/guides/pdf-to-html-conversion-quality): The planned 50-document pilot for conversion fidelity and routing safety; the corpus is not yet labelled and no accuracy result is published. - [Editorial policy](https://docaccessible.com/editorial-policy): How DocAccessible researches, reviews, dates, sources, and corrects public content. - [Accessibility statement](https://docaccessible.com/accessibility-statement): The site's accessibility commitments, known boundaries, and barrier-reporting route. - [Accessibility conformance report](https://docaccessible.com/vpat): Product accessibility evaluation scope and documented support statements. - [Legal center](https://docaccessible.com/legal): The agreements, policies, and operational disclosures that apply to DocAccessible. - [Terms of Service](https://docaccessible.com/terms): The agreement governing accounts, subscriptions, customer content, and use of the platform. - [Privacy Policy](https://docaccessible.com/privacy): How account, document, contact, billing, analytics, and support data is handled. - [Cookie Policy](https://docaccessible.com/cookies): The essential storage used by the service and the optional analytics you control. - [Acceptable Use Policy](https://docaccessible.com/acceptable-use): Rules that protect customer files, the platform, connected websites, and other users. - [Billing & Refund Policy](https://docaccessible.com/refund-policy): Subscription cancellation, billing errors, refunds, taxes, and manual-service charges. - [Data Processing Addendum](https://docaccessible.com/dpa): Business-customer terms for personal data contained in customer files and workflows. - [Subprocessors](https://docaccessible.com/subprocessors): The provider categories used for hosting, AI analysis, email, payments, and monitoring. - [Security Overview](https://docaccessible.com/security): Current application safeguards, customer responsibilities, and vulnerability reporting. - [Copyright Complaints](https://docaccessible.com/copyright): How rights owners can report material published through a customer-controlled page. - [Manual Services Terms](https://docaccessible.com/manual-services-terms): The $5-per-page, 501-page-minimum terms for agency-led PDF remediation projects. - [Plans and pricing](https://docaccessible.com/pricing): Current plan limits, included workflows, and purchase options. - [About DocAccessible](https://docaccessible.com/about): Product purpose, operating principles, and company context. - [Contact DocAccessible](https://docaccessible.com/contact): Contact product support, request manual remediation, or report an accessibility barrier.