# 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-09-02 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. ## Key facts Manual PDF remediation pricing: - Rate: $5 USD per accepted source page, flat regardless of page complexity. - Minimum project: 501 source pages, so the smallest eligible engagement is $2,505 USD before applicable tax. - Scope: exact-layout repair of the original PDF, performed by a specialist, billed separately from any software plan. - Projects of 500 pages or fewer are not accepted at this rate; use the software plans or coordinate an independent vendor through Exchange. Software plan pricing and enforced allowances: - Free: $0. 3 documents per month, files up to 10 MB, 1 seat, 2 active Exchange cases, monitoring for 1 website and up to 20 PDFs. - Exchange: $19 per month. No automated remediation allowance, files up to 50 MB, 3 seats, 250 active Exchange cases, monitoring for 1 website and up to 100 PDFs. - Pro: $29 per month. 50 documents per month, files up to 50 MB, 1 seat, 10 active Exchange cases, monitoring for 3 websites and up to 250 PDFs. - Team: $49 per month. 200 documents per month, files up to 50 MB, 5 seats, 50 active Exchange cases, monitoring for 10 websites and up to 2,000 PDFs. - Organization: $199 per month. 500 documents per month, files up to 100 MB, 25 seats, 250 active Exchange cases, monitoring for 25 websites and up to 5,000 PDFs. - Billing runs month to month and can be cancelled from the billing portal at any time. - Reaching a monthly document limit pauses new uploads until reset or upgrade. There are no automatic overage charges. - The Free plan requires no credit card. Standards and output: - Automated checks are mapped to WCAG 2.2 Level AA. Generated PDFs are aligned to PDF/UA. - Automated checking and generated output do not certify WCAG, PDF/UA, ADA, or Section 508 conformance. - Hosted accessible HTML is responsive and published from the platform. The rebuilt tagged PDF reproduces the same content for offline use and may change layout or pagination. - Preserving the exact source-PDF appearance requires the manual remediation path above. - Scanned and OCR-derived pages are detected and routed to reviewed OCR or specialist remediation rather than automatic tagging. Regulatory dates referenced on this site: - ADA Title II: public entities with a population of 50,000 or more must comply by April 26, 2027. - ADA Title II: public entities under 50,000 population, and special district governments, have until April 26, 2028. Free tools requiring no account: website PDF scanner, PDF-to-HTML converter, PDF accessibility checker, PDF tag viewer, PDF auto-tagger, and scanned-PDF text recovery. ## Common questions Canonical answer page: https://docaccessible.com/answers ### Pricing and cost **How much does PDF accessibility remediation cost?** DocAccessible charges $5 USD per accepted source page for manual PDF remediation, and the rate is flat regardless of how complex a page is. The agency team takes bulk projects above 500 pages, so the smallest eligible project is 501 pages at $2,505 before applicable tax. Automated remediation is priced separately as a monthly software subscription rather than per page. Source: https://docaccessible.com/services/pdf-accessibility-remediation (canonical answer page: https://docaccessible.com/answers#manual-pdf-remediation-cost) **How much does DocAccessible cost per month?** DocAccessible software plans are Free at $0, Exchange at $19 per month, Pro at $29 per month, Team at $49 per month, and Organization at $199 per month. Each paid plan raises the monthly document allowance, upload size, seat count, active Exchange cases, and website PDF monitoring limits. Subscriptions run month to month and can be cancelled from the billing portal at any time. Source: https://docaccessible.com/pricing (canonical answer page: https://docaccessible.com/answers#software-plan-pricing) **Do you charge per page or per document?** The two paths are priced differently. Software plans are billed per month with a document allowance, so a 90-page report and a two-page memo each count as one document. Manual agency remediation is billed per source page at $5 USD, with no complexity multiplier. Source: https://docaccessible.com/pricing (canonical answer page: https://docaccessible.com/answers#per-page-or-per-document) **What if my PDF project is 500 pages or fewer?** The DocAccessible agency team focuses on bulk projects above 500 pages, so smaller jobs are not accepted at the per-page rate. For a smaller project, use the software plans to generate and review accessible output yourself, or use Exchange to coordinate an independent remediation vendor through the same workflow. Source: https://docaccessible.com/services/pdf-accessibility-remediation (canonical answer page: https://docaccessible.com/answers#smallest-remediation-project) **Is there a free plan, and is a credit card required?** Yes, there is a Free plan and no card is required. It covers three documents per month, files up to 10 MB, automated checks, hosted accessible HTML, a rebuilt tagged PDF, public and unlisted share links, and monitoring of one website with up to 20 PDFs. Source: https://docaccessible.com/pricing (canonical answer page: https://docaccessible.com/answers#free-plan-and-credit-card) **What happens when I reach my monthly document limit?** New uploads pause until the next monthly reset or until the plan is upgraded. Existing documents, hosted pages, downloads, and edits stay available, and no automatic overage charges are applied. Source: https://docaccessible.com/pricing (canonical answer page: https://docaccessible.com/answers#monthly-limit-behaviour) ### Output formats **What is the difference between hosted accessible HTML and a tagged PDF?** Hosted HTML is responsive, fast to publish, easy to edit, and generally gives assistive technology a more reliable reading experience. The automated tagged PDF rebuilds the same content for offline use and may change the original layout or pagination. Keeping the exact source-PDF appearance is a separate manual remediation path. Source: https://docaccessible.com/remediation-options (canonical answer page: https://docaccessible.com/answers#hosted-html-vs-tagged-pdf) **Will remediation preserve my PDF's exact layout?** Only the manual path is designed to. Automated rebuilding can reflow a document, so pagination and visual placement may change. Manual exact-layout remediation repairs the accessibility structure without intentionally rebuilding the design, although a defect in the source file can still require a discussed visual adjustment. Source: https://docaccessible.com/remediation-options (canonical answer page: https://docaccessible.com/answers#preserve-exact-layout) **Can a scanned PDF be tagged automatically?** No. A scanned page is an image with no text layer, so automatic tagging has no structure to work with. DocAccessible detects scanned and OCR-derived pages and routes them to reviewed OCR text recovery or to specialist remediation instead of producing a tag structure that would be wrong. Source: https://docaccessible.com/tools/make-scanned-pdf-accessible (canonical answer page: https://docaccessible.com/answers#scanned-pdf-handling) **Can my team edit the remediated result?** Yes. The browser editor adjusts headings, alternative text, reading order, captions, and table structure. Saving runs the accessibility checks again, so the change in findings is visible immediately, and every saved version is retained as release evidence. Source: https://docaccessible.com/features/document-accessibility-review (canonical answer page: https://docaccessible.com/answers#editing-the-result) ### Creating accessible PDFs **Does Google Docs export a tagged, accessible PDF?** Yes. Google announced on December 6, 2024 that PDFs downloaded from Google Docs include structural and accessibility tags for paragraphs, headings, hyperlinks, image alt text, and lists, with rollout complete by mid-January 2025 for Workspace and personal accounts, and added tags for tables, equations, and checkboxes in March 2025. The export tags only what the document declares, so headings must use heading styles and images need alt text, and the result should be checked with a tag viewer and checker. Source: https://docaccessible.com/guides/google-docs-to-accessible-pdf (canonical answer page: https://docaccessible.com/answers#google-docs-tagged-pdf) **Why does printing to PDF remove accessibility tags?** A PDF printer receives drawing instructions for each page and has no concept of headings, lists, tables, or image descriptions, so the file it writes has no tag structure at all. In Word, Excel, and PowerPoint on Windows, use File, Save As, PDF, Options with "Document structure tags for accessibility" selected; on macOS use the "Best for electronic distribution and accessibility" export. Microsoft Print to PDF and third-party PDF printers should not be used for documents that must be accessible. Source: https://docaccessible.com/guides/word-save-as-pdf-vs-print-to-pdf (canonical answer page: https://docaccessible.com/answers#print-to-pdf-loses-tags) **Can Canva export an accessible PDF?** Canva embeds accessibility tags when a design is downloaded as PDF Standard with the Flatten PDF checkbox unchecked; Canva states that flattening removes the tags. Heading levels follow the text styles (Title is H1, Subtitle H2, and so on), alt text and a screen reader language can be set, and reading order is calculated from position or matched to layer order. Canva documents that browser PDF viewers and macOS Preview may skip content, and recommends checking exported files in Adobe Acrobat. Source: https://docaccessible.com/guides/canva-pdf-accessibility (canonical answer page: https://docaccessible.com/answers#canva-accessible-pdf) **Can LaTeX produce an accessible tagged PDF?** Yes, on a current LaTeX release. Placing \DocumentMetadata{tagging=on} before \documentclass and compiling with LuaLaTeX produces tagged output; pdfstandard=ua-2 targets PDF/UA-2, lang sets the language, and alt= on \includegraphics adds image descriptions. The LaTeX Project recommends LuaLaTeX and a release of 2025-11-01 or later, tracks support per package on its tagging status pages, and provides MathML-based tagged math through tagging-setup. Source: https://docaccessible.com/guides/latex-accessible-pdf (canonical answer page: https://docaccessible.com/answers#latex-tagged-pdf) **Does Chrome or Puppeteer generate tagged PDFs?** Chrome has generated a tagged PDF from the print dialog's Save as PDF option since Chrome 85 in August 2020, carrying headings, lists, tables, paragraphs, and image descriptions from the page. Puppeteer's page.pdf() exposes a tagged option that defaults to true and an outline option for bookmarks that defaults to false. The tags mirror the HTML's semantics, so the page needs real headings, alt attributes, table headers, lang, and a title, and the output should be validated with a PDF/UA checker. Source: https://docaccessible.com/guides/tagged-pdf-from-html-chrome-puppeteer-prince (canonical answer page: https://docaccessible.com/answers#chrome-puppeteer-tagged-pdf) **Which applications export tagged PDFs?** Microsoft Word, Excel, and PowerPoint (through Save As with the structure tags option, or the accessibility export on macOS), Google Docs (since December 2024), Apple Pages, Numbers, and Keynote (since version 8.2 in 2019), Canva (PDF Standard, not flattened), Adobe InDesign (with Create Tagged PDF), LaTeX (with tagging enabled), and Chrome (since version 85). Print-to-PDF drivers and scanners write no tags. A tagged export still needs headings, alt text, table headers, a title, and a language in the source. Source: https://docaccessible.com/guides/which-apps-export-tagged-pdfs (canonical answer page: https://docaccessible.com/answers#which-apps-tagged-pdf) ### Standards and compliance **What accessibility standards does DocAccessible check against?** Every document receives automated checks mapped to WCAG 2.2 Level AA, covering structure, images, headings, tables, landmarks, language, and link text. The generated PDF is aligned to PDF/UA. Layout-critical or high-stakes documents still require manual validation. Source: https://docaccessible.com/guides/wcag-2-2-aa (canonical answer page: https://docaccessible.com/answers#standards-checked) **Does automated remediation certify WCAG, PDF/UA, or ADA compliance?** No. Automated checking, scores, and generated output assist accessibility work but do not certify conformance, and no provider or automated checker should promise a universal legal guarantee. Reading order, complex tables, charts, forms, and contextual alternative text can require qualified human review with representative assistive technology. Source: https://docaccessible.com/editorial-policy (canonical answer page: https://docaccessible.com/answers#conformance-certification) **What is the difference between PDF/UA and WCAG?** PDF/UA is a machine-checkable specification for the technical structure of a PDF file, so a checker can verify it deterministically. WCAG is an outcome-oriented standard about whether a person can actually perceive, operate, and understand the content. A file can pass PDF/UA validation and still fail WCAG, which is why the two complement rather than replace one another. Source: https://docaccessible.com/guides/pdf-ua-vs-wcag (canonical answer page: https://docaccessible.com/answers#pdf-ua-vs-wcag) **What is PDF/UA-2?** PDF/UA-2 is ISO 14289-2, published in 2024, the accessibility standard for PDF files based on PDF 2.0. It was built from the PDF Association's free WTPDF specification and adds comprehensive rules for structure element attributes and annotations, PDF 2.0 structure types, MathML for mathematics, structure destinations for internal links, and Associated Files. PDF/UA-1 remains the standard for PDF 1.7 files and is not replaced; no major accessibility regulation names PDF/UA-2 as a legal requirement. Source: https://docaccessible.com/guides/pdf-ua-2-explained (canonical answer page: https://docaccessible.com/answers#what-is-pdf-ua-2) **What is the Matterhorn Protocol?** The Matterhorn Protocol is the PDF Association's conformance testing model for PDF/UA-1. Version 1.1, released April 22, 2021, defines 31 checkpoints containing 136 failure conditions, each tied to a clause of ISO 14289-1. 87 of the conditions can be determined by software, 47 usually require human judgement, and 2 have no specific test. Checkers such as PAC report against these numbered conditions, which is why a clean automated report still leaves the human-judgement checks open. Source: https://docaccessible.com/guides/matterhorn-protocol-explained (canonical answer page: https://docaccessible.com/answers#what-is-matterhorn-protocol) **Is a PDF/A file accessible?** Not necessarily. PDF/A (ISO 19005) is an archival standard for long-term preservation. Its level a variants (PDF/A-1a, 2a, 3a) require tags and Unicode text but only their presence, not their correctness, and PDF/A-4 makes tags optional. Accessibility is the job of PDF/UA (ISO 14289), which requires semantically correct structure, alternatives, language, title, and security settings that allow assistive technology. One file can conform to both, for example PDF/A-2a together with PDF/UA-1. Source: https://docaccessible.com/guides/pdf-a-vs-pdf-ua (canonical answer page: https://docaccessible.com/answers#is-pdf-a-accessible) **Does a PDF need bookmarks to be accessible?** Adobe Acrobat's accessibility checker fails a document of 21 or more pages that has no bookmarks paralleling its structure, and WCAG technique PDF2 recommends bookmarks for navigation. PDF/UA-1 has no bookmark rule: the Matterhorn Protocol's navigation checkpoint states that no specific test is required. Bookmarks remain good practice for any long document and can be generated from headings in Word's Save As options, in Acrobat, and through Puppeteer's outline option. Source: https://docaccessible.com/guides/pdf-document-settings-checkers-flag (canonical answer page: https://docaccessible.com/answers#pdf-bookmarks-required) **What is a VPAT and how is it different from an ACR?** A VPAT (Voluntary Product Accessibility Template) is the blank template published by the Information Technology Industry Council; a VPAT completed for a specific product version is an Accessibility Conformance Report (ACR). The current template is VPAT 2.5Rev (April 2025) in four editions: 508, EU (EN 301 549), WCAG (2.0, 2.1, and 2.2), and INT. Each criterion is rated Supports, Partially Supports, Does Not Support, or Not Applicable with remarks. ITI does not review or certify completed reports. Source: https://docaccessible.com/guides/vpat-acr-explained (canonical answer page: https://docaccessible.com/answers#what-is-a-vpat) **Are old PDFs exempt from the ADA Title II web rule?** Only if they were available before the public entity's compliance date and are not currently used to apply for, gain access to, or participate in the entity's services, programs, or activities (28 CFR 35.201(b)). Any form, application, or instruction still in use is in scope regardless of age. Content kept purely for reference in a clearly identified archive area and unchanged since archiving is separately excepted, and the DOJ states that labelling content archived does not create the exception. Source: https://docaccessible.com/guides/ada-title-ii-document-exceptions (canonical answer page: https://docaccessible.com/answers#title-ii-old-pdfs-exempt) **Which PDF viewer should I use to test with a screen reader?** Adobe Acrobat Reader on Windows with NVDA or JAWS is the reference environment for tagged PDF semantics, and Firefox is a strong second because its viewer has exposed tagged PDF structure since Firefox 89 in July 2021. PowerMapper's December 2025 tests scored NVDA with Firefox at 88% and JAWS with Firefox at 75% on tagged PDF features, against 25% for either screen reader with Chrome or Edge, whose shared viewer does not expose the same headings and table headers. Source: https://docaccessible.com/guides/test-pdf-with-screen-reader (canonical answer page: https://docaccessible.com/answers#best-viewer-screen-reader-pdf-test) ### Deadlines **When is the ADA Title II web accessibility deadline?** State and local government entities with a population of 50,000 or more must comply by April 26, 2027. Public entities with a population under 50,000, and special district governments, have until April 26, 2028. The substantive technical requirement is WCAG 2.1 Level AA, and it applies to public-facing documents such as PDFs, not only to web pages. Source: https://docaccessible.com/guides/ada-title-ii-2026 (canonical answer page: https://docaccessible.com/answers#ada-title-ii-deadline) **When is the HHS Section 504 web accessibility deadline for health providers?** May 11, 2027 for recipients of HHS financial assistance with fifteen or more employees, and May 10, 2028 for recipients with fewer than fifteen. HHS extended both dates by one year through an interim final rule effective May 7, 2026; they were originally May 11, 2026 and May 10, 2027. The technical standard is WCAG 2.1 Level AA for web content and mobile apps, including PDFs and other documents, and the rule's provisions mirror the ADA Title II web rule. Source: https://docaccessible.com/guides/hhs-section-504-web-document-accessibility (canonical answer page: https://docaccessible.com/answers#hhs-section-504-deadline) **When must Canadian federal organizations make documents accessible?** Under the Regulations Amending the Accessible Canada Regulations registered December 5, 2025, the federal public sector must ensure new or updated web pages conform to CAN/ASC-EN 301 549:2024 from December 5, 2027, and new or updated non-web documents and mobile applications from December 5, 2028. Federally regulated businesses with 500 or more employees have December 5, 2028 for web pages, apps, and documents; those with 100 to 499 employees have that date for web pages only; smaller businesses are exempt. Source: https://docaccessible.com/guides/canada-document-accessibility-aca-aoda (canonical answer page: https://docaccessible.com/answers#canada-document-accessibility-deadline) **What does the European Accessibility Act require for documents?** The European Accessibility Act (Directive 2019/882) has applied since June 28, 2025 to listed products and services including e-readers, e-books, consumer banking, and e-commerce. Its requirements are functional and set out in Annex I; it excludes office file formats published before June 28, 2025 from its website content requirements and exempts microenterprises providing services. EN 301 549, whose clause 10 applies WCAG-derived requirements to downloadable documents, is being revised to serve as the harmonised standard under the Act. Source: https://docaccessible.com/guides/en-301-549-documents-eaa (canonical answer page: https://docaccessible.com/answers#eaa-documents) **Do UK public sector PDFs published before September 2018 have to be accessible?** Not unless users need them to use a service. GOV.UK lists PDFs and other documents published before 23 September 2018 among the content exempt from the Public Sector Bodies Accessibility Regulations 2018, except documents needed to use a service, such as a form. Documents published or updated since that date, or still needed for a service, must meet WCAG 2.2 AA, which the Government Digital Service has monitored against since October 2024. Source: https://docaccessible.com/guides/uk-public-sector-pdf-accessibility (canonical answer page: https://docaccessible.com/answers#uk-old-pdfs) **What is the deadline for Colorado HB21-1110?** Colorado state and local government entities had to adopt an accessibility plan by July 1, 2022 and fully comply with the Office of Information Technology's accessibility standards, which set WCAG 2.1 Level AA, by July 1, 2024. HB24-1454 extended immunity from liability to July 1, 2025 for entities demonstrating good-faith efforts. That grace period has ended, and the statute provides a $3,500 statutory fine payable to each plaintiff for each violation. OIT states the law covers documents as well as websites and software. Source: https://docaccessible.com/guides/colorado-hb21-1110-documents (canonical answer page: https://docaccessible.com/answers#colorado-hb21-1110-deadline) ### Free tools **Is there a free PDF accessibility checker?** Yes. DocAccessible publishes six free browser tools with no account required: a website PDF scanner, a PDF-to-HTML converter, an accessibility checker, a tag viewer, an auto-tagger, and a scanned-PDF text recovery tool. The checker runs machine-detectable structural and PDF/UA-oriented checks and keeps the findings that still need manual review. Source: https://docaccessible.com/tools (canonical answer page: https://docaccessible.com/answers#free-pdf-accessibility-checker) **How can I find every PDF published on a website?** The free DocAccessible website PDF scanner takes a domain and lists the public PDFs the site links to, where each file is linked from, and automated checks on the most-linked files. It runs anonymously in the browser with no script to install and no account. Source: https://docaccessible.com/tools/website-pdf-scanner (canonical answer page: https://docaccessible.com/answers#find-pdfs-on-a-website) ### Working with vendors **Can our existing remediation vendor work through DocAccessible?** Yes. Exchange is included in every software plan, so an existing vendor can be invited to a restricted, case-scoped portal. The workspace receives immutable revisions, records review decisions, and delivers one approved file through an expiring link. External vendors are restricted case participants rather than internal seats, and remediation labor is not included in any software plan. Source: https://docaccessible.com/exchange (canonical answer page: https://docaccessible.com/answers#existing-vendor) ## 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) ## Accessibility guides Guides index: https://docaccessible.com/guides ### Which apps export tagged PDFs? Word, Google Docs, Pages, Canva, InDesign, LaTeX, and browsers compared Canonical URL: https://docaccessible.com/guides/which-apps-export-tagged-pdfs A vendor-sourced matrix of which authoring tools write PDF tags on export, which setting turns them on, and where each one still needs a manual check. - Category: Authoring and export - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - A PDF is only accessible to assistive technology if it carries a tag structure, and whether it gets one depends almost entirely on which export path the authoring tool used. - Microsoft Word, Excel, and PowerPoint write tags through Save As with the document structure option on Windows, or the "Best for electronic distribution and accessibility" option on macOS; Print to PDF writes none. - Google Docs has exported structural tags since a December 2024 rollout, Apple Pages has exported tagged PDF since version 8.2 in 2019, and Canva keeps tags only in a PDF Standard export that is not flattened. - Chrome has produced tagged PDF from Save as PDF since version 85 in 2020, and LaTeX produces tagged output when tagging is enabled through \DocumentMetadata on a current release. - Tagged is not the same as accessible: every path still needs alt text, real headings, table headers, a title, and a language, followed by a check. #### Questions answered **Does "tagged PDF" mean the PDF is accessible?** No. A tag structure is the prerequisite that lets assistive technology read structure at all, but the tags must also be correct: real headings at the right level, table header cells marked, meaningful images described, decorative ones artifacted, and a document title and language set. Export tools write tags from whatever the author gave them, so a poorly structured source produces a poorly tagged PDF. **Why did my exported PDF lose all its headings?** The most common cause is exporting through a print dialog or virtual printer, which draws the pages and writes no structure. In Word, Excel, and PowerPoint use Save As with the document structure tags option, or the accessibility export option on macOS. The second most common cause is text that was made large and bold by hand rather than assigned a heading style. **Which tool produces the most reliable tagged PDF?** Reliability depends more on the author than the tool. Word with proper styles, Google Docs with real headings, and InDesign with mapped styles and an Articles order all export well. Layout-heavy design tools and any print-based path are the weakest. Whatever the source, check the tag tree and run an automated check before publishing. #### Sources - Microsoft Support: Create accessible PDFs: https://support.microsoft.com/en-us/office/create-accessible-pdfs-064625e0-56ea-4e16-ad71-3aa33bb4b7ed (Windows and macOS export options for Word, Excel, and PowerPoint, and the rights-management limitation.) - WebAIM: PDF Accessibility, Converting Documents to PDF: https://webaim.org/techniques/acrobat/converting (Why Save As rather than Print produces a tagged PDF.) - Google Workspace Updates, December 6, 2024: improved accessibility tagging in PDFs exported from Google Docs: https://workspaceupdates.googleblog.com/2024/12/release-notes-12-06-2024.html (Paragraphs, headings, hyperlinks, image alt text, and lists; rollout complete by mid-January 2025.) - Google Workspace Updates, March 2025: additional accessibility tags for tables, equations, and checkboxes: https://workspaceupdates.googleblog.com/2025/03/ - PDF Association: Apple tags PDF (November 13, 2019): https://pdfa.org/apple-tags-pdf/ (Pages, Numbers, and Keynote 8.2 export tagged PDF on macOS and iOS.) - Apple Support: Export to Word, PDF, or another file format in Pages on Mac: https://support.apple.com/guide/pages/export-to-word-pdf-or-another-file-format-tance1161f26/mac (Image descriptions are exported; accessibility tags for large tables are under Advanced Options.) - Canva Help Center: PDF accessibility features: https://www.canva.com/help/pdf-accessibility-features/ (PDF Standard export, the Flatten PDF caveat, reading order, text semantics, and the browser-viewer known issue.) - Adobe: Use tags for accessible PDFs in InDesign: https://helpx.adobe.com/indesign/desktop/interactive-elements-and-forms/forms-and-pdfs/use-tags-for-accessible-pdfs.html - LaTeX Project: Using LaTeX to produce accessible PDF: https://latex3.github.io/tagging-project/documentation/usage-instructions - Chromium Blog, July 29, 2020: Using Chrome to generate more accessible PDFs: https://blog.chromium.org/2020/07/using-chrome-to-generate-more.html - Puppeteer API: PDFOptions: https://pptr.dev/api/puppeteer.pdfoptions (The `tagged` option, marked experimental, defaults to true.) - Firefox Source Docs: Tagged PDF Output: https://firefox-source-docs.mozilla.org/accessible/TaggedPdfOutput.html ### Google Docs to accessible PDF: what the export tags now, and what you still have to check Canonical URL: https://docaccessible.com/guides/google-docs-to-accessible-pdf Google Docs has exported tagged PDFs since December 2024. What the tagging covers, how to prepare the document, and the checks to run before you publish. - Category: Authoring and export - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Since a rollout announced on December 6, 2024, PDFs downloaded from Google Docs carry structural tags for paragraphs, headings, hyperlinks, image alt text, and lists, with tables, equations, and checkboxes added in March 2025. - The export can only tag what the document declares: heading styles, alt text on images, and real lists, so preparation in Docs decides the result. - Advice to export through Word first dates from before the change and is no longer necessary for most documents, although it remains a valid route. - After export, check the tag tree, the document title, the language, table headers, and reading order, then run an automated checker. #### Questions answered **Does Google Docs export tagged PDFs?** Yes. Google announced on December 6, 2024 that PDFs exported from Google Docs include structural and accessibility tags for paragraphs, headings, hyperlinks, image alt text, and lists, with rollout completing by mid-January 2025, and added tags for tables, equations, and checkboxes in March 2025. The export tags what the document declares, so headings must be heading styles and images need alt text. **Do I still need to export through Word for an accessible PDF?** Not for most documents. That workaround dates from when Docs exported untagged PDFs. Exporting through Word remains valid, and is useful when you want Word's PDF options such as bookmarks from headings or PDF/A, but it is no longer required to get a tag structure. **Is a PDF exported from Google Docs WCAG or PDF/UA conformant?** Google's announcements describe improved tagging and do not claim conformance with WCAG or PDF/UA. Conformance depends on the source document and on checks the export cannot make, such as alt text quality and reading order. Verify the file with a tag viewer, an automated checker, and a screen reader before making any claim. #### Sources - Google Workspace Updates, December 6, 2024: Adding improved accessibility tagging to PDFs exported from Google Docs: https://workspaceupdates.googleblog.com/2024/12/release-notes-12-06-2024.html - Google Workspace Updates, March 2025: Additional accessibility tags for Tables, Equations, and Checkboxes in PDFs exported from Google Docs: https://workspaceupdates.googleblog.com/2025/03/ - Google Docs Editors Help: Use Google Docs Editors with a screen reader: https://support.google.com/docs/answer/6282736?hl=en - W3C WAI: PDF16, setting the default language with the /Lang entry: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF16 - W3C WAI: PDF18, specifying the document title: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF18 ### Word to PDF: why Save As keeps accessibility tags and Print to PDF throws them away Canonical URL: https://docaccessible.com/guides/word-save-as-pdf-vs-print-to-pdf The exact Word, Excel, and PowerPoint settings on Windows and macOS that produce a tagged PDF, why printing to PDF produces an untagged one, and what to fix in the source first. - Category: Authoring and export - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - On Windows, File > Save As > PDF > Options with "Document structure tags for accessibility" selected writes a tagged PDF from Word, Excel, and PowerPoint. - On macOS, Save as PDF with "Best for electronic distribution and accessibility (uses Microsoft online service)" is the tagged path; the file is processed by Microsoft's service. - Printing to any PDF driver draws the pages and writes no structure, which is why a printed PDF has no headings, no alt text, and no reading order. - Tags copy what the source declares: use heading styles, alt text, real lists, and a marked header row before exporting, then verify the PDF. #### Questions answered **Does Microsoft Print to PDF create an accessible PDF?** No. Print to PDF, like any PDF printer, draws the pages and writes no tag structure, so the file has no headings, lists, table headers, or alt text for assistive technology. Use File > Save As with the document structure tags option on Windows, or the electronic distribution and accessibility option on macOS. **Where is the "Document structure tags for accessibility" option?** In Word, Excel, or PowerPoint for Windows, choose File > Save As, set the file type to PDF, and select Options. The checkbox is in the Options dialog alongside "Create bookmarks using" and "PDF/A compliant". It is normally selected by default, but confirm it before saving. **Why does Word for Mac say the accessible export uses an online service?** Because the tagged export on macOS is produced by a Microsoft service rather than locally. Microsoft names the option "Best for electronic distribution and accessibility (uses Microsoft online service)". Files protected by rights management or an open password cannot use it in Excel and PowerPoint until the protection is removed. #### Sources - Microsoft Support: Create accessible PDFs: https://support.microsoft.com/en-us/office/create-accessible-pdfs-064625e0-56ea-4e16-ad71-3aa33bb4b7ed (Step-by-step export settings for Windows and macOS, the PowerPoint hyperlink note, and the rights-management limitation.) - WebAIM: PDF Accessibility, Converting Documents to PDF: https://webaim.org/techniques/acrobat/converting - Adobe: Create and verify PDF accessibility (Acrobat Pro): https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html (The Bookmarks check fails when a document has 21 or more pages and no bookmarks paralleling the structure.) ### Canva PDF accessibility: the export settings that keep tags, and the limits Canva itself documents Canonical URL: https://docaccessible.com/guides/canva-pdf-accessibility How to export a Canva design as a tagged PDF, set reading order and heading semantics, add alt text and a language, and where Canva says the result may still fail. - Category: Authoring and export - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Canva embeds accessibility tags only when a design is downloaded as PDF Standard with the Flatten PDF checkbox unchecked; flattening removes all tags. - Reading order is calculated from element position on export and works best for simple linear layouts; for anything else, order the layers and select "Match reading order to layers". - Heading levels follow Canva's text styles (Title is H1, Subtitle H2, Heading H3, Subheading H4, Section header H5) and can be edited under File > Accessibility. - Canva documents a known issue where browser PDF viewers, macOS Preview, and Safari with VoiceOver may skip content, and recommends checking in Adobe Acrobat. #### Questions answered **Does Canva export accessible PDFs?** Canva exports tagged PDFs when you download a design as PDF Standard with the Flatten PDF option unchecked. The export includes heading semantics from text styles, alt text, a screen reader language, and a reading order calculated from element position or from layer order. Canva itself notes the result works best for simple layouts and may not read correctly in browser viewers or macOS Preview. **Why does my Canva PDF have no tags?** The most likely cause is the Flatten PDF checkbox, which merges the design into an image and removes tags, or exporting as PDF Print rather than PDF Standard. Re-export as PDF Standard with flattening off and confirm the structure in a tag viewer. **How do I fix the reading order of a Canva PDF?** Open Position to view the layers, arrange them in reading order with the first-read element at the bottom, and select "Match reading order to layers" in the download dialog. Canva's automatic order is calculated from position and is reliable only for simple linear designs. #### Sources - Canva Help Center: PDF accessibility features: https://www.canva.com/help/pdf-accessibility-features/ (Export steps, the Flatten PDF caveat, reading order, text semantics mapping, alt text, language, and the documented browser-viewer issue.) - Canva Help Center: Edit text semantics for PDF accessibility: https://www.canva.com/help/edit-text-semantics/ - PowerMapper: PDFs, screen reader compatibility (December 14, 2025): https://www.powermapper.com/tests/screen-readers/pdf/ (Independent test results across NVDA, JAWS, and VoiceOver with browser PDF engines.) ### Accessible PDFs from LaTeX: the tagging project, \DocumentMetadata, and what works in 2026 Canonical URL: https://docaccessible.com/guides/latex-accessible-pdf How to produce tagged, PDF/UA-2 targeted output from LaTeX with \DocumentMetadata, which engine to use, how to add alt text and tagged math, and where package support still limits results. - Category: Authoring and export - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Tagging is enabled by placing \DocumentMetadata{tagging=on} before \documentclass; the LaTeX Project recommends a current release (2025-11-01 or 2026-06-01) and LuaLaTeX for new documents. - pdfstandard=ua-2 targets PDF/UA-2 and can be combined with a PDF/A part such as a-4f; the document language is set with the lang key. - Images take alt=, artifact, or actualtext= keys on \includegraphics, which also work for TikZ and picture environments. - Tagged math is available through tagging-setup={math/setup=mathml-SE} on LuaLaTeX; pdfLaTeX is supported but needs external MathML files for math. - Support is being added package by package and is tracked on the project's tagging status pages, so check the packages a document loads. #### Questions answered **Can LaTeX produce an accessible tagged PDF?** Yes, on a current LaTeX release. Placing \DocumentMetadata{tagging=on} before \documentclass and compiling with LuaLaTeX produces tagged output, with pdfstandard=ua-2 targeting PDF/UA-2, lang setting the language, and alt= keys on \includegraphics for image descriptions. Support depends on the packages a document loads, which the LaTeX Project tracks on its tagging status pages. **Which engine should I use for tagged LaTeX output?** The LaTeX Project recommends LuaLaTeX for new documents and describes it as the preferred engine. pdfLaTeX is supported but requires external MathML files for tagged math. The project's usage instructions do not cover XeLaTeX. **How do I add alt text to a figure in LaTeX?** Use the alt key on \includegraphics, for example \includegraphics[alt={Line chart of monthly temperature}]{figure.pdf}. Use the artifact key for decorative images and actualtext for images that stand in for a character or short string. The same keys work for TikZ and picture environments. #### Sources - LaTeX Project: Using LaTeX to produce accessible PDF (usage instructions): https://latex3.github.io/tagging-project/documentation/usage-instructions (The \DocumentMetadata keys, engine recommendations, release guidance, graphics keys, and math setup quoted in this guide.) - LaTeX Project: The LaTeX Tagged PDF Project: https://latex3.github.io/tagging-project/ - Overleaf: Creating accessible PDFs in LaTeX: https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs - veraPDF validation profiles: PDF/UA Part 2 rules: https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFUA-Part-2-rules ### Generating tagged PDFs from HTML: Chrome and Puppeteer, Prince, WeasyPrint, and how to validate the output Canonical URL: https://docaccessible.com/guides/tagged-pdf-from-html-chrome-puppeteer-prince For developers generating PDFs from HTML: which engines write tags, the flags that control them, why the HTML's semantics decide the result, and how to validate against PDF/UA. - Category: Authoring and export - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Chrome has written tagged PDF from Save as PDF since Chrome 85 (August 2020), and Puppeteer's page.pdf() exposes this as a `tagged` option that defaults to true; an `outline` option, off by default, adds bookmarks. - Prince produces PDF/UA-1 through --pdf-profile, including combined PDF/A-2a+PDF/UA-1 output, and can fail the build when a profile's requirements are not met. - WeasyPrint accepts --pdf-variant pdf/ua-1 or pdf/ua-2 and a pdf_tags option, but its documentation states the generated documents are not guaranteed to be valid. - wkhtmltopdf has long-standing open requests for tagged output and should not be used where accessibility is required. - Tags are derived from the HTML, so headings, alt attributes, table headers, lang, and a title in the source decide the result; validate with veraPDF or PAC before shipping. #### Questions answered **Does Puppeteer generate accessible PDFs?** Current Puppeteer exposes a tagged option on page.pdf() that defaults to true and produces a tagged PDF using Chrome's tagging, which Chrome has supported since version 85. An outline option, off by default, adds bookmarks. The tags mirror the page's HTML semantics, so headings, alt attributes, table headers, and lang must be present in the HTML, and the output should still be validated. **Which HTML-to-PDF engine supports PDF/UA?** Prince documents a PDF/UA-1 profile and combined PDF/A plus PDF/UA-1 profiles. WeasyPrint accepts pdf/ua-1 and pdf/ua-2 variants but states its output is not guaranteed valid. Chrome and Puppeteer write tagged PDF without targeting a PDF/UA profile. iText's pdfHTML documents PDF/UA output for Java and .NET. Validate any of them with veraPDF or PAC. **Can I make wkhtmltopdf output accessible?** Not in practice. wkhtmltopdf has open requests for tagged output that have not been implemented, and its files carry no structure, alt text, or language. Move the rendering step to an engine that writes tags, such as Chrome, Prince, or WeasyPrint, rather than trying to add tags afterwards. #### Sources - Chromium Blog, July 29, 2020: Using Chrome to generate more accessible PDFs: https://blog.chromium.org/2020/07/using-chrome-to-generate-more.html - Puppeteer API reference: PDFOptions: https://pptr.dev/api/puppeteer.pdfoptions (The tagged (default true) and outline (default false) options.) - Puppeteer issue #7509: Export tagged PDFs for Accessibility: https://github.com/puppeteer/puppeteer/issues/7509 (History of the earlier gap between Chrome's print dialog and Puppeteer output.) - Firefox Source Docs: Tagged PDF Output: https://firefox-source-docs.mozilla.org/accessible/TaggedPdfOutput.html - Prince documentation: PDF output and profiles: https://www.princexml.com/doc/prince-output/ (PDF/UA-1 profile, combined PDF/A plus PDF/UA-1 profiles, --tagged-pdf, and --fail-pdf-profile-error.) - WeasyPrint documentation: API reference: https://doc.courtbouillon.org/weasyprint/stable/api_reference.html (The pdf/ua-1 and pdf/ua-2 variants, pdf_tags, and the statement that output is not guaranteed valid.) - wkhtmltopdf issue #1616: not generating accessible PDFs: https://github.com/wkhtmltopdf/wkhtmltopdf/issues/1616 - iText: Making PDF/A document creation easier with iText and pdfHTML: https://itextpdf.com/blog/technical-notes/easier-pdfa-pdfhtml - veraPDF documentation: CLI validation: https://docs.verapdf.org/cli/validation/ - PAC: PDF Accessibility Checker: https://pac.pdf-accessibility.org/en ### PDF/UA-2 explained: what ISO 14289-2 changes for PDF 2.0, and when you actually need it Canonical URL: https://docaccessible.com/guides/pdf-ua-2-explained PDF/UA-2 (ISO 14289-2:2024) is the accessibility standard for PDF 2.0 files. What it adds over PDF/UA-1, its relationship to WTPDF, and which tools produce or validate it today. - Category: Standards and formats - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - PDF/UA-2 is ISO 14289-2, published in 2024, and specifies accessible PDF files built on PDF 2.0 (ISO 32000-2); PDF/UA-1 (ISO 14289-1, 2012, revised 2014) covers PDF 1.7 and is not replaced by it. - The technical content of PDF/UA-2 is the PDF Association's WTPDF (Well-Tagged PDF) specification from February 2024, which is free; the ISO document must be purchased. - Compared with PDF/UA-1 it adds comprehensive rules for structure element attributes and annotations, the new PDF 2.0 structure types, math with MathML, intra-document links through structure destinations, and Associated Files. - Regulations such as the ADA Title II rule and EN 301 549 name WCAG rather than PDF/UA, so PDF/UA-2 is a technical route to those outcomes, not a separate legal requirement. - Producer and validator support exists (LaTeX, WeasyPrint, veraPDF) but viewer support for PDF 2.0 structure is uneven, so test output with real assistive technology. #### Questions answered **What is PDF/UA-2?** PDF/UA-2 is ISO 14289-2, published in 2024, the standard for accessible PDF files based on PDF 2.0 (ISO 32000-2). It was built from the PDF Association's free WTPDF specification and adds comprehensive rules for structure element attributes and annotations, PDF 2.0 structure types, MathML for math, structure destinations for internal links, and Associated Files. PDF/UA-1 remains the standard for PDF 1.7 files. **Is PDF/UA-2 backward compatible with PDF/UA-1?** The two parts are written against different PDF versions, so a file conforms to one or the other rather than both: PDF/UA-1 for PDF 1.7 and PDF/UA-2 for PDF 2.0. PDF/UA-2 does not withdraw or replace PDF/UA-1, and PDF/UA-1 remains widely implemented and referenced. **Do I need PDF/UA-2 to comply with accessibility law?** No regulation checked for this guide names PDF/UA-2. The ADA Title II rule, EN 301 549, and the UK public sector regulations all require WCAG-based outcomes. PDF/UA-2 is a technical route to those outcomes and useful procurement evidence, particularly for math-heavy documents, but a PDF/UA identifier is not compliance on its own. #### Sources - PDF Association, March 15, 2024: ISO 14289-2 (PDF/UA-2), the gold standard for accessibility in PDF 2.0, has arrived: https://pdfa.org/iso-14289-2-pdf-ua-2-the-gold-standard-for-accessibility-in-pdf-2-0-has-arrived/ (Publication, relationship to WTPDF and PDF/UA-1, and the list of enhancements quoted here.) - PDF Association: ISO 14289-2 (PDF/UA-2) resource page: https://pdfa.org/iso-14289-2-pdfua-2/ - LaTeX Project: Using LaTeX to produce accessible PDF: https://latex3.github.io/tagging-project/documentation/usage-instructions - WeasyPrint documentation: API reference: https://doc.courtbouillon.org/weasyprint/stable/api_reference.html - Prince documentation: PDF output and profiles: https://www.princexml.com/doc/prince-output/ - veraPDF validation profiles: PDF/UA Part 2 rules: https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFUA-Part-2-rules - eCFR: 28 CFR Part 35, Subpart H, Web and Mobile Accessibility: https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H (The Title II rule names WCAG 2.1 Level A and AA.) ### The Matterhorn Protocol: 31 checkpoints and 136 failure conditions, explained for people who are not PDF engineers Canonical URL: https://docaccessible.com/guides/matterhorn-protocol-explained What the Matterhorn Protocol is, how its 31 checkpoints and 136 failure conditions test PDF/UA-1, which ones a machine can decide, and how to read a checker report built on it. - Category: Standards and formats - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - The Matterhorn Protocol is the PDF Association's testing model for PDF/UA-1 (ISO 14289-1): 31 checkpoints containing 136 failure conditions, each tied to a clause of the standard. - 87 failure conditions can be determined by software alone, 47 usually require human judgement, and 2 have no specific test (23-001 on digital signatures and 27-001 on navigation). - Version 1.1 was released on April 22, 2021, adding one failure condition and clarifications; the document is free and is itself a reference-quality PDF/UA-1 and PDF/A-2a file. - Checkers such as PAC report against these conditions, which is why they can flag things Acrobat's checker does not, and why a clean machine result still leaves 47 human decisions. - The protocol covers PDF/UA-1 only; it has no page-count rule for bookmarks, and its navigation checkpoint says no specific test is required. #### Questions answered **What is the Matterhorn Protocol?** The Matterhorn Protocol is the PDF Association's conformance testing model for PDF/UA-1 (ISO 14289-1). Version 1.1, released April 22, 2021, defines 31 checkpoints containing 136 failure conditions, each tied to a clause of the standard. 87 conditions can be determined by software, 47 usually require human judgement, and 2 have no specific test. PDF/UA checkers such as PAC report against these conditions. **Does the Matterhorn Protocol require bookmarks?** No. Its navigation checkpoint, 27, contains a single entry stating that no tests specific to navigation are required. The rule that documents of 21 or more pages need bookmarks is Adobe Acrobat's own accessibility checker rule, not a PDF/UA-1 failure condition, although bookmarks remain a recommended WCAG technique. **Does the Matterhorn Protocol apply to PDF/UA-2?** The Matterhorn Protocol 1.1 is written for PDF/UA-1 and ISO 14289-1. PDF/UA-2 (ISO 14289-2) covers PDF 2.0 and is tested through validators that publish PDF/UA-2 profiles, such as veraPDF. Check the PDF Association for current testing material for the newer standard. #### Sources - PDF Association: Matterhorn Protocol 1.1, PDF/UA Conformance Testing Model (PDF): https://pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf (Checkpoint list, counts of machine and human conditions, and the failure conditions quoted.) - PDF Association, April 22, 2021: Rules for Accessible PDF, Matterhorn Protocol 1.1 is now available: https://pdfa.org/rules-for-accessible-pdf-matterhorn-protocol-1-1-is-now-available/ - Adobe: Create and verify PDF accessibility (Acrobat Pro): https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html (Acrobat's bookmarks rule for documents of 21 or more pages.) - W3C WAI: PDF2, creating bookmarks in PDF documents: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF2 ### PDF/A vs PDF/UA: archival and accessible are different jobs, and a file can do both Canonical URL: https://docaccessible.com/guides/pdf-a-vs-pdf-ua PDF/A preserves a document for the long term; PDF/UA makes it usable with assistive technology. What each level guarantees, why PDF/A-1a is not accessibility, and how to produce files that satisfy both. - Category: Standards and formats - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - PDF/A (ISO 19005) is for long-term preservation: embedded fonts, no external dependencies, and reproducible appearance. PDF/UA (ISO 14289) is for accessibility: a correct tag structure, alternatives, and metadata that assistive technology can use. - PDF/A's level a (PDF/A-1a, 2a, 3a) requires tags and Unicode text, but as PDFlib's guidance puts it, those levels "require only the mere presence of tags" and say nothing about whether the tags are right. - PDF/A-4 (2020, based on PDF 2.0) dropped the a, b, and u levels entirely and adds e and f variants; tags are encouraged but optional. - One file can conform to both standards: the Matterhorn Protocol PDF is published as PDF/UA-1 and PDF/A-2a, and Prince offers combined PDF/A-2a+PDF/UA-1 output. - Courts and archives that require PDF/A do not thereby require accessibility, so a records policy needs both requirements stated. #### Questions answered **Is a PDF/A file accessible?** Not necessarily. PDF/A (ISO 19005) is an archival standard. Its level a variants (PDF/A-1a, 2a, 3a) require tags and Unicode text but only their presence, not their correctness, and PDF/A-4 makes tags optional. Accessibility is the job of PDF/UA (ISO 14289), which requires semantically correct structure, alternatives, language, title, and security settings that allow assistive technology. A file can conform to both. **Can a PDF be both PDF/A and PDF/UA?** Yes. The PDF Association publishes the Matterhorn Protocol as a file conforming to PDF/UA-1 and PDF/A-2a, and tools such as Prince offer combined PDF/A-2a+PDF/UA-1 output. The file must be correctly tagged, use embedded fonts and device-independent colour, and must not be encrypted, since PDF/A forbids encryption. **Which PDF/A level should I use if I also want accessibility?** For PDF 1.7 files, PDF/A-2a or PDF/A-3a combined with PDF/UA-1, since level a requires the tag structure PDF/UA builds on. For PDF 2.0 files, PDF/A-4 with tagging enabled combined with PDF/UA-2. In every case validate the accessibility side separately; the PDF/A level alone does not check it. #### Sources - PDFlib knowledge base: The PDF/A standards: https://www.pdflib.com/pdf-knowledge-base/pdfa/the-pdfa-standards/ (Parts, base versions, conformance levels, PDF/A-4 changes, and the quoted statement on level a.) - PDF Association: What is PDF/A?: https://pdfa.org/what-is-pdfa-understanding-the-pdf-standard-for-long-term-archiving/ - PDF Association, April 22, 2021: Matterhorn Protocol 1.1 is now available: https://pdfa.org/rules-for-accessible-pdf-matterhorn-protocol-1-1-is-now-available/ (The protocol PDF conforms to both PDF/UA-1 and PDF/A-2a.) - Prince documentation: PDF output and profiles: https://www.princexml.com/doc/prince-output/ (Combined PDF/A plus PDF/UA-1 profiles.) - United States Courts: Electronic Filing (CM/ECF): https://www.uscourts.gov/court-records/electronic-filing-cm-ecf - U.S. District Court, Eastern District of Oklahoma: PDF/A Frequently Asked Questions: https://www.oked.uscourts.gov/pdfa-frequently-asked-questions - Datalogics: XFA forms deprecated, what it means and what to do: https://www.datalogics.com/xfa-form-deprecation-what-it-means-and-what-to-do (XFA is not permitted in PDF/A.) ### Title, language, bookmarks, tab order, security: the five document-level PDF settings every checker flags Canonical URL: https://docaccessible.com/guides/pdf-document-settings-checkers-flag The document-level PDF settings that fail accessibility checks most often: title and DisplayDocTitle, language, bookmarks, tab order, and the permission that lets screen readers read text. Where each lives and which rule tests it. - Category: Standards and formats - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Five settings that have nothing to do with the tag tree cause a large share of checker failures: the document title, the document language, bookmarks, tab order, and the security permission for assistive technology. - A title needs two things: the Title entry in the document metadata, and the DisplayDocTitle viewer preference set to true so viewers show it instead of the file name (Matterhorn 06-003 and 07-001/07-002). - The document language is the /Lang entry in the catalog (W3C technique PDF16); Acrobat's checker reports it as Primary language. - Acrobat fails a document of 21 or more pages without bookmarks paralleling its structure; PDF/UA-1 has no such rule, but bookmarks are a WCAG technique (PDF2). - If a PDF is encrypted, the permission that allows text extraction for assistive technology must be set, or the file is unreadable to screen readers regardless of its tags. #### Questions answered **Why does a screen reader read the file name instead of the PDF's title?** Because either the Title metadata is empty or the viewer preference DisplayDocTitle is not set to true. Set the title in Document Properties and, under Initial View, set Show to Document Title. PDF/UA-1 tests both through Matterhorn conditions 06-003 and 07-001/07-002, and Acrobat's checker reports them together as the Title rule. **Does a PDF need bookmarks to be accessible?** Adobe Acrobat's checker fails a document of 21 or more pages that has no bookmarks paralleling its structure, and WCAG technique PDF2 recommends bookmarks for navigation. PDF/UA-1 has no bookmark rule; its navigation checkpoint states that no specific test is required. Bookmarks are good practice for any long document and can be generated from headings in Word, Acrobat, and Puppeteer. **What is the "accessibility permission flag" in Acrobat's checker?** The accessibility permission flag reports whether an encrypted PDF allows assistive technology to extract text. The PDF specification reserves a permission bit for that purpose, PDF/UA-1 requires it (Matterhorn 26-001 and 26-002), and in Acrobat's security settings it is the option labelled "Enable text access for screen reader devices for the visually impaired". Without it, screen readers cannot read the document however well it is tagged. #### Sources - Adobe: Create and verify PDF accessibility (Acrobat Pro): https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html (The Accessibility permission flag, Title, Primary language, Bookmarks (21 or more pages), and Tab order rules as worded by Adobe.) - PDF Association: Matterhorn Protocol 1.1 (PDF): https://pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf (Failure conditions 06-003, 06-004, 07-001, 07-002, 11-001, 26-001, 26-002, and 27-001.) - W3C WAI: PDF18, specifying the document title: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF18 - W3C WAI: PDF16, setting the default language with the /Lang entry: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF16 - W3C WAI: PDF2, creating bookmarks in PDF documents: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF2 - W3C WAI: PDF3, ensuring correct tab and reading order: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF3 - Adobe LiveCycle documentation: Using PDF security options: https://help.adobe.com/en_US/livecycle/10.0/DesignerHelp/WS92d06802c76abadb-728f46ac129b395660c-7f83.html (Wording and encryption-level note for the screen reader text access permission.) ### Language tagging in PDFs: the document language, passages in other languages, and the five places PDF/UA checks Canonical URL: https://docaccessible.com/guides/pdf-language-tagging-multilingual How to declare a PDF's language and mark passages in other languages so screen readers pronounce them correctly, which WCAG techniques and PDF/UA conditions apply, and how to handle bilingual documents. - Category: Standards and formats - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - A screen reader picks its pronunciation rules and voice from the declared language, so an undeclared or wrong language makes correctly tagged text sound like nonsense. - The document language is the /Lang entry in the PDF catalog (WCAG technique PDF16, success criterion 3.1.1); a passage in another language gets its own structure element with a Lang entry (PDF19, success criterion 3.1.2). - PDF/UA-1 checks language in five places: page content, Alt and ActualText and E attributes, outline entries, annotation contents, and form field tooltips (Matterhorn checkpoint 11). - For bilingual documents, declare the primary language on the document and tag each section in the other language; do not leave a mixed document with a single language. #### Questions answered **How do I set the language of a PDF?** Set the /Lang entry in the document catalog, which WCAG technique PDF16 describes. In Acrobat it is Document Properties > Advanced > Reading Options > Language, or the Primary language fix in the accessibility checker. In Word, set the proofing language before Save As PDF. In generated PDFs it usually comes from the HTML lang attribute or a metadata option. **How do I mark a passage in another language in a PDF?** Give the passage its own structure element with a Lang entry, as WCAG technique PDF19 describes. In Acrobat, select the text, use Create Tag From Selection, then set the language in the tag's properties. This satisfies success criterion 3.1.2 and lets screen readers switch voices for the passage. **Does alternative text need its own language?** Only when it differs from the document language. PDF/UA-1 condition 11-002 fails a file where the language of Alt, ActualText, or E attributes cannot be determined; normally the document-level language is inherited. If an English document carries French alt text, put a Lang on the figure element. #### Sources - W3C WAI: PDF16, setting the default language using the /Lang entry in the document catalog: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF16 - W3C WAI: PDF19, specifying the language for a passage or phrase with the Lang entry: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF19 (The Acrobat procedure and the ISO 639 code note.) - PDF Association: Matterhorn Protocol 1.1 (PDF): https://pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf (Checkpoint 11 failure conditions 11-001 to 11-005.) - Adobe: Create and verify PDF accessibility (Acrobat Pro): https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html (The Primary language rule and its fix.) - ETSI EN 301 549 V3.2.1 (2021-03), clause 10.3.1 Readable: https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf ### Accessible PDF forms: AcroForm vs XFA, field names and tooltips, tab order, and what WCAG expects Canonical URL: https://docaccessible.com/guides/accessible-pdf-forms-acroform-xfa Why XFA forms fail accessibility and archiving, how AcroForm fields get an accessible name through tooltips, the WCAG PDF techniques for forms, and when an HTML form is the better answer. - Category: Standards and formats - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - XFA forms are no longer part of PDF 2.0, are not permitted in PDF/A, and are unsupported or only partially supported in browser and mobile viewers; PDF/UA-1 fails a dynamic XFA form outright. AcroForm is the interoperable and accessible form technology. - Each AcroForm field needs an accessible name, which screen readers take from the field's tooltip (the TU entry), plus a tag in the structure tree in reading order and a tab order that follows the document structure. - The WCAG PDF techniques for forms are PDF5 (required fields), PDF10 (labels), PDF12 (name, role, value), PDF15 (submit buttons), PDF22 (input errors), PDF23 (interactive controls), and PDF3 (tab and reading order). - The ADA Title II rule never exempts documents currently used to apply for or participate in a service, so public forms are in scope regardless of when they were posted. - For public forms that many people complete, an HTML form is usually more accessible and easier to maintain than a fillable PDF. #### Questions answered **Are XFA forms accessible?** In practice, no. XFA is no longer part of PDF 2.0, is not permitted in PDF/A, and is unsupported or only partially supported by browser and mobile PDF viewers, which flatten or refuse XFA forms. PDF/UA-1 fails a dynamic XFA form outright through Matterhorn condition 25-001. Migrating XFA forms to AcroForm or HTML is the first step in making them accessible. **How does a screen reader know what a PDF form field is for?** From the field's tooltip, stored as the TU entry, which supplies the accessible name that WCAG technique PDF12 requires alongside role and value. The tooltip should match the visible label and include any instruction, such as a date format. The field must also be tagged in the structure tree at its reading position and sit in a tab order that follows the document structure. **Is an old PDF form exempt under the ADA Title II rule?** No. The rule's exception for preexisting conventional electronic documents does not apply to documents currently used to apply for, gain access to, or participate in a public entity's services, programs, or activities, which covers any form still in use. The UK public sector regulations have the same carve-out for pre-2018 documents that users need to use a service. #### Sources - PDFlib knowledge base: PDF 2.0 deprecated features: https://www.pdflib.com/pdf-knowledge-base/pdf-20/deprecated-features/ (XFA forms are no longer part of PDF 2.0.) - Datalogics: XFA forms deprecated, what it means and what to do: https://www.datalogics.com/xfa-form-deprecation-what-it-means-and-what-to-do (XFA not permitted in PDF/A; browser and mobile viewer support.) - W3C WAI: WCAG 2.2 Techniques, PDF techniques PDF3, PDF5, PDF10, PDF12, PDF15, PDF22, PDF23: https://www.w3.org/WAI/WCAG22/Techniques/ - Section508.gov: Electronic Signatures: https://www.section508.gov/create/electronic-signatures/ (Tooltips matching labels, logical tab order, keyboard use, and scanned signature blocks as figures.) - PDF Association: Matterhorn Protocol 1.1 (PDF): https://pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf (Failure conditions 11-005, 24-001, 25-001, and 28-001.) - eCFR: 28 CFR 35.201, Exceptions: https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H - GOV.UK: Understanding accessibility requirements for public sector bodies: https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps ### Acrobat's accessibility checker vs PAC: what each report means, and why a pass is not conformance Canonical URL: https://docaccessible.com/guides/acrobat-checker-vs-pac Why a PDF can pass Adobe Acrobat's accessibility checker and fail PAC, what each tool actually tests, how to read their reports, and what neither can decide. - Category: Testing and evidence - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Acrobat's checker runs Adobe's own set of rules, several of which are marked "Needs Manual Check"; PAC tests against the PDF/UA-1 failure conditions of the Matterhorn Protocol and WCAG requirements, so the two disagree by design. - PAC is free, has been maintained since 2010, is funded by the German Federal Ministry of Labour and Social Affairs, and its current release is PAC 2026, which adds AI-assisted checks alongside the screen reader preview. - Of the Matterhorn Protocol's 136 failure conditions, 47 usually require human judgement, so an empty error list from any tool still leaves reading order, heading logic, table relationships, and alt text quality to a person. - Read a report by fixing machine-decidable errors first, then working the manual items, and never describe a clean report as certification. #### Questions answered **Why does my PDF pass Acrobat's checker but fail PAC?** Because they test different rule sets. Acrobat applies Adobe's own checks, several of them manual, while PAC tests the PDF/UA-1 failure conditions of the Matterhorn Protocol and WCAG requirements. PAC fails a file with no PDF/UA identifier in its metadata, for instance, which Acrobat does not test, while Acrobat fails a long document without bookmarks, which PDF/UA-1 does not require. **Is PAC free?** Yes. PAC, the PDF Accessibility Checker, is free, needs no admin rights to install, and is funded by the German Federal Ministry of Labor and Social Affairs. It has been maintained since 2010 and its current release is PAC 2026, which adds AI-assisted checks to the PDF/UA and WCAG tests and the screen reader preview. **Does passing PAC mean a PDF is PDF/UA compliant?** No. PAC tests the machine-decidable conditions and prompts for the visual and manual checks. The Matterhorn Protocol that PDF/UA-1 testing is based on classifies 47 of its 136 failure conditions as usually requiring human judgement, and WCAG adds outcome-based requirements beyond PDF/UA. A clean PAC report plus documented manual checks is strong evidence; a clean report alone is not conformance. #### Sources - Adobe: Create and verify PDF accessibility (Acrobat Pro): https://helpx.adobe.com/acrobat/using/create-verify-pdf-accessibility.html (The checker's rules, the Needs Manual Check status, and the wording of the Bookmarks and Title rules.) - PAC: PDF Accessibility Checker: https://pac.pdf-accessibility.org/en (Funding, history since 2010, PDF/UA and WCAG scope, screen reader preview, and the PAC 2026 release.) - PDF Association: Matterhorn Protocol 1.1 (PDF): https://pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf (87 machine-decidable, 47 human-judgement, and 2 untested failure conditions.) - veraPDF documentation: CLI validation: https://docs.verapdf.org/cli/validation/ - veraPDF validation profiles: PDF/UA Part 2 rules: https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFUA-Part-2-rules ### How to test a PDF with a screen reader: NVDA, JAWS, and VoiceOver, and which viewers actually expose the tags Canonical URL: https://docaccessible.com/guides/test-pdf-with-screen-reader A repeatable screen reader test for PDFs with NVDA, JAWS, or VoiceOver: which viewer to open the file in, the keystrokes to use, what to listen for, and independent data on which viewers expose tags. - Category: Testing and evidence - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - The viewer matters as much as the screen reader: independent tests published in December 2025 scored NVDA and JAWS with Firefox's PDF viewer at 88% and 75% on PDF accessibility features, against 25% for the same screen readers with Chrome or Edge. - Adobe Acrobat Reader on Windows with NVDA (free) or JAWS remains the reference environment for tagged PDF semantics; Canva and others document that browser viewers and macOS Preview may skip content that Acrobat reads correctly. - Firefox's built-in viewer has exposed tagged PDF structure since Firefox 89 in July 2021, which is why it scores well; Chromium-based viewers do not expose the same structure to screen readers. - A useful test takes 15 minutes: title, headings list, reading order, tables, images, links, forms, and language switching, recorded with the viewer and screen reader versions used. #### Questions answered **Which screen reader and viewer should I use to test a PDF?** Use Adobe Acrobat Reader on Windows with NVDA, which is free, as the reference environment, then repeat in Firefox. Independent tests published by PowerMapper in December 2025 scored NVDA with Firefox at 88% and JAWS with Firefox at 75% on tagged PDF features, against 25% for either screen reader with Chrome or Edge, whose shared viewer does not expose the same structure. **Why does my tagged PDF read badly in Chrome?** Chromium's built-in PDF viewer, used by Chrome and Edge, does not expose tagged PDF structure such as headings and table headers to screen readers the way Acrobat Reader and Firefox do. If the file reads correctly in Acrobat Reader with NVDA, the tags are correct and the limitation is the viewer. Publishing an HTML version alongside the PDF is the reliable fix for readers who use Chrome. **Does Firefox support tagged PDFs?** Yes. Beginning with Firefox 89, released July 1, 2021, the built-in PDF.js viewer exposes the structure tree of tagged PDFs to screen readers, which is why Firefox scores well in independent PDF screen reader tests. It is a good second environment after Acrobat Reader for checking headings, tables, and alternative text. #### Sources - PowerMapper: PDFs, screen reader compatibility (December 14, 2025): https://www.powermapper.com/tests/screen-readers/pdf/ (Reliability scores by screen reader and browser PDF engine, and the list of features tested.) - Fondazione LIA: Firefox PDF viewer now supports tagged PDF: https://www.fondazionelia.org/en/research-and-development/firefox-pdf-viewer-now-supports-tagged-pdf/ (Firefox 89, released July 1, 2021.) - Mozilla PDF.js pull request #13171: add support for basic structure tree for accessibility: https://github.com/mozilla/pdf.js/pull/13171 - Canva Help Center: PDF accessibility features: https://www.canva.com/help/pdf-accessibility-features/ (Documented issue with browser viewers, macOS Preview, and Safari with VoiceOver.) - NV Access: NVDA screen reader: https://www.nvaccess.org/ - Apple Support: Use VoiceOver in apps on iPhone: https://support.apple.com/guide/iphone/use-voiceover-in-apps-iphe4ee74be8/ios ### Section 508 document testing: the ICT Testing Baseline for Electronic Documents and what federal testers check Canonical URL: https://docaccessible.com/guides/section-508-document-testing-baseline The Section 508 ICT Testing Baseline for Electronic Documents (version 1.0, September 2024): its 24 tests, who wrote it, how it relates to the Revised 508 Standards and WCAG, and how to use it outside government. - Category: Testing and evidence - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - The ICT Testing Baseline for Electronic Documents, version 1.0 released September 30, 2024, is the U.S. federal reference for testing non-web documents such as PDF, Word, Excel, and PowerPoint files for Section 508 conformance. - The Baseline was authored by the Accessible Electronic Documents Community of Practice (AED COP), a cross-agency group formed in October 2012, with a Baseline for Documents Technical Advisory Committee. - The Baseline has 24 numbered tests, from Keyboard Accessible to Parsing, three of which are marked not applicable to documents; each maps to WCAG 2.0 success criteria as incorporated by the Revised 508 Standards. - Section508.gov states that federal policy requires agencies to prioritise HTML and use PDFs only when necessary, which is the strongest signal in the guidance. - Outside government, the Baseline is a free, test-by-test definition of "accessible document" that procurement teams can cite instead of a vendor's own checklist. #### Questions answered **What is the ICT Testing Baseline for Electronic Documents?** The ICT Testing Baseline for Electronic Documents is the U.S. federal reference for testing non-web documents, such as PDF, Word, Excel, and PowerPoint files, for Section 508 conformance. Version 1.0 was released on September 30, 2024, on the Access Board's ICT Testing Baseline portfolio site, authored by the Accessible Electronic Documents Community of Practice. It defines 24 tests, three of them not applicable to documents, each mapped to WCAG success criteria. **What does "508 compliant PDF" actually mean?** In a defensible sense it means the PDF has passed every applicable test in the ICT Testing Baseline for Electronic Documents, including the manual ones, with the results recorded. The Revised 508 Standards incorporate WCAG 2.0 Level A and AA for electronic content, so the tests cover keyboard access, images, contrast, forms, titles, tables, structure, links, language, reading order, and parsing. **Can a private company use the Section 508 document Baseline?** Yes. The Baseline is public and free, and it is a precise definition of an accessible document that any organisation can adopt for procurement or internal review. It is written by WCAG outcome rather than by tool, so it applies to Word, Excel, and PowerPoint files as well as PDFs, and it separates what must be true of a document from how a checker tests it. #### Sources - U.S. Access Board: ICT Testing Baseline for Electronic Documents: https://ictbaseline.access-board.gov/document-baselines/ (Version 1.0 release date, scope statement, and the list of 24 tests.) - U.S. Access Board: Section 508 ICT Testing Baseline Portfolio: https://ictbaseline.access-board.gov/ - Section508.gov: Create Accessible PDFs: https://www.section508.gov/create/pdfs/ (Federal policy to prioritise HTML and use PDFs only when necessary.) - Section508.gov: Module 0, Introduction and Background (PDF training): https://www.section508.gov/training/pdfs/aed-cop-pdf00/ (The AED COP's formation in October 2012.) - Section508.gov: Module 2, Testing a PDF for Accessibility: https://www.section508.gov/training/pdfs/aed-cop-pdf02/ (Guidance based on the Section 508 Baseline Test Guide for PDFs and the Section 508 PDF Checklist.) - Section508.gov: Electronic Documents Overview (testing): https://www.section508.gov/test/documents/ ### Alt text for charts and graphs in PDFs: the short description, the long description, and when to use a data table Canonical URL: https://docaccessible.com/guides/alt-text-charts-graphs-pdf How to write text alternatives for charts, graphs, and infographics in PDFs using the two-part pattern W3C recommends: a short alt on the figure and a long description or data table in the document. - Category: Content techniques - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - W3C's guidance for complex images calls for a two-part text alternative: a short description that identifies the image and says where the long description is, and a long description that gives the essential information the image conveys. - In a PDF the short description is the Alt entry on the Figure tag, which PDF/UA-1 requires (Matterhorn 13-004); the long description is ordinary tagged content next to the figure, and for most charts the best long description is a data table. - A good chart alt names the chart type, the subject, and the conclusion a sighted reader would draw; it does not list colours, repeat the caption, or try to hold every value. - Infographics are usually several charts and a narrative in one image; the accessible version is the narrative as headings and text with each chart handled separately. #### Questions answered **How do I write alt text for a chart in a PDF?** Use a two-part alternative. Put a short description on the Figure tag's Alt entry that names the chart type, its subject, and the conclusion a reader should draw, and says where the detail is. Then provide the detail as tagged content after the figure: a data table with header cells for charts with discrete values, or prose describing axes, trends, and notable points for charts that show a shape. PDF/UA-1 requires the Alt entry; the long description is what makes it useful. **Can a data table replace alt text for a chart?** No, but it is the best long description. The Figure still needs a short alt so a screen reader user knows what the image is and where its data lives. The table then gives the exact values, navigable cell by cell, which is more than the chart gives a sighted reader. Tag it as a real Table with TH header cells and Scope attributes. **How long should chart alt text be?** A few sentences: type, subject, conclusion, and a pointer to the long description. There is no fixed character limit in WCAG, but long alt is hard to navigate and cannot hold structure, so values, comparisons, and trends belong in the tagged long description or data table rather than in the Alt entry. #### Sources - W3C WAI: Images Tutorial, Complex Images: https://www.w3.org/WAI/tutorials/images/complex/ (The two-part text alternative and the approaches for long descriptions.) - W3C WAI: PDF1, applying text alternatives to images with the Alt entry: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF1 - W3C WAI: PDF4, hiding decorative images with the Artifact tag: https://www.w3.org/WAI/WCAG22/Techniques/pdf/PDF4 - PDF Association: Matterhorn Protocol 1.1 (PDF): https://pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf (Failure conditions 13-003, 13-004, and checkpoint 15 on tables.) - Government of Canada Digital Accessibility Toolkit: Alternative text and long description, best practices: https://a11y.canada.ca/en/alternative-text-and-long-description-best-practices/ ### Maps, floor plans, and engineering drawings in PDFs: what an accessible alternative actually looks like Canonical URL: https://docaccessible.com/guides/accessible-maps-floor-plans-drawings Spatial graphics cannot be made accessible with a sentence of alt text. How to provide equivalent access to maps, site plans, floor plans, and technical drawings, and what the law says about them. - Category: Content techniques - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - A map or drawing is a spatial answer to a question; the accessible alternative answers the same question in text or data, which means first deciding what the graphic is for. - Wayfinding maps need text directions or an address list; boundary and zoning maps need a table of what applies to each parcel or area; floor plans need a room list with adjacency and accessible routes; drawings need their title block, notes, and dimensions as real text. - WCAG success criterion 1.1.1 has no exception for maps, and neither does the ADA Title II rule; the European Accessibility Act excludes online maps from its website requirements only where essential information is provided in an accessible digital manner, and Canada's amended regulations require maps and technical drawings to conform only to the extent feasible. - Keep text in plans and drawings as real, extractable text rather than outlines, and route complex spatial documents to specialist review rather than automated tagging. #### Questions answered **How do I make a map in a PDF accessible?** Decide what question the map answers and provide that answer in text or a table: directions and addresses for wayfinding maps, a table of areas and what applies in each for boundary or zoning maps, and a data table with a summary of the pattern for thematic maps. Tag the map itself as a Figure with a short alt that names its subject and points to the alternative, and keep any labels as real text. **Are maps exempt from WCAG or the ADA Title II rule?** No. WCAG success criterion 1.1.1 has no exception for maps, and the ADA Title II rule adopts WCAG 2.1 AA without one; the DOJ fact sheet even uses a current park map PDF as an example of covered content. The European Accessibility Act excludes online maps from its website requirements only where essential information is provided in an accessible digital manner, and Canada's regulations require maps and drawings to conform to the extent feasible. **What is the accessible alternative for a floor plan?** A room list by floor with names, numbers, and functions, a statement of what each room connects to, and accessible routes and exits described as sequences of turns and distances. The plan is tagged as a Figure with a short alt pointing to that list. Carnegie Museums' guidance also suggests in-person assistance or a tactile or 3D model for complex spaces. #### Sources - W3C WAI: Images Tutorial, Complex Images: https://www.w3.org/WAI/tutorials/images/complex/ - Carnegie Museums of Pittsburgh: Web Accessibility Guidelines, Maps: http://web-accessibility.carnegiemuseums.org/content/maps/ - ADA.gov: Fact Sheet, New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments: https://www.ada.gov/resources/2024-03-08-web-rule/ (The park map example under the archived content exception.) - EUR-Lex: Directive (EU) 2019/882, Article 2(4)(c): https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng - Canada Gazette, Part II, December 17, 2025: Regulations Amending the Accessible Canada Regulations (SOR/2025-255): https://gazette.gc.ca/rp-pr/p2/2025/2025-12-17/html/sor-dors255-eng.html (Maps, technical drawings, and images conform to the extent feasible.) ### E-signatures and accessible PDFs: what Acrobat Sign and DocuSign preserve, and why remediation must come first Canonical URL: https://docaccessible.com/guides/e-signatures-and-tagged-pdfs How signing platforms handle PDF tags, what Adobe and Docusign document about accessible envelopes, why a digital signature freezes the file, and the order of operations that keeps signed documents accessible. - Category: Content techniques - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Adobe states that tagging in Acrobat Sign "is only supported when a properly tagged PDF is uploaded as the source document", that participant-entered content is then tagged, and that Acrobat Sign cannot create an accessible PDF from an inaccessible source. - Docusign targets WCAG 2.2 Level AA for its signing experience, publishes VPATs, and provides guidance on preparing an accessible PDF before sending; community reports show completed envelopes can still fail tagged-annotation checks, so the completed file must be checked. - A digital signature covers the signed bytes, so adding or editing tags afterwards changes what was signed and viewers report the signature as invalid; accessibility work has to be finished before the document is signed. - Never print, sign by hand, and scan: the result is an image with no text and no structure. Section508.gov's guidance treats scanned signature blocks as figures needing alternative text. #### Questions answered **Are documents signed with DocuSign or Acrobat Sign accessible?** Only if the document was accessible before it was sent. Adobe states that Acrobat Sign preserves tagging only when a properly tagged PDF is uploaded and cannot create an accessible PDF from an inaccessible source; Docusign's guidance likewise starts with preparing an accessible PDF and named fields. The completed file should then be checked, since platform stamps and added pages can introduce untagged elements. **Can I add accessibility tags to a PDF after it has been digitally signed?** Not without invalidating the signature. A digital signature is a hash of the signed bytes, so any edit, including tagging, causes viewers to report the document as altered since signing. Finish remediation before signing, keep the accessible unsigned master, and if a signed file is inaccessible provide an accessible copy or re-execute the signature on a remediated file. **What is the correct order for making a signed PDF accessible?** Author accessibly and export with tags; remediate and test the PDF; add and name the form fields including the signature field, with tooltips and a tab order that follows the structure; enable tagged output in the signing platform; sign; then verify the completed file with a tag viewer, a checker, and a screen reader, and record the result. #### Sources - Adobe Acrobat Sign: Create accessible PDFs (updated August 2, 2023): https://helpx.adobe.com/sign/authoring/create-accessible-pdfs.html (Tag preservation only for tagged sources, participant content tagging, the workflow, and the Enable Tagged PDF Generation setting.) - Docusign Accessibility Hub: https://www.docusign.com/accessibility (WCAG 2.2 AA target, VPATs, recommended screen reader combinations, and the accessible envelope guidance.) - Docusign Community: What element is not tagged in these documents?: https://community.docusign.com/esignature-111/what-element-is-not-tagged-in-these-documents-25988 (Community report of a completed envelope failing a tagged-annotation check.) - Section508.gov: Electronic Signatures: https://www.section508.gov/create/electronic-signatures/ (Tooltips and tab order for signature fields, scanned signature blocks as figures, and procurement of signing software.) - PDF Association: Matterhorn Protocol 1.1 (PDF): https://pdfa.org/wp-content/uploads/2021/04/Matterhorn-Protocol-1-1.pdf (Checkpoint 23, digital signatures.) ### Accessible statements, bills, and notices at scale: fixing the template instead of the document Canonical URL: https://docaccessible.com/guides/accessible-statements-notices-at-scale How to make high-volume transactional documents (statements, bills, explanations of benefits, notices) accessible by fixing the template and composition pipeline, what the law expects, and how to validate by sample. - Category: Content techniques - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Statements, bills, and notices are generated from templates by the thousand, so accessibility is a property of the template and the composition engine, not of individual files; fix it once at the source. - The ADA Title II rule excepts individualized, password-protected conventional electronic documents such as a water or tax bill, but not the portal that delivers them, and the effective communication duty remains; the HHS Section 504 rule mirrors this. - The European Accessibility Act brings consumer banking services and e-commerce into scope from June 28, 2025, with Annex I requiring identification, security, and payment functions to be perceivable, operable, understandable, and robust. - Validate per template version with a sample of generated documents, using a PDF/UA validator in the pipeline and a screen reader pass, and give each document a unique title and the customer's language. #### Questions answered **Do bank statements and bills have to be accessible?** For U.S. public entities, the ADA Title II rule excepts individualized, password-protected documents such as a water or tax bill from its WCAG requirement, but the delivery portal is covered and the effective communication duty means an accessible bill must be provided on request. In the EU, consumer banking services are in scope of the European Accessibility Act from June 28, 2025. For private U.S. businesses no document standard is named, and accessible statements plus alternative formats on request are the defensible position. **How do you make thousands of generated PDFs accessible?** By fixing the template and the composition output rather than the documents. Configure the engine to emit tagged PDF or generate from semantic HTML, make transaction tables real tables with header cells, add data tables for charts, set a unique title and the customer's language, mark running headers as artifacts, and permit assistive technology access if files are encrypted. Then validate a sample from each template version with a PDF/UA validator and a screen reader. **Why are statements converted from print streams inaccessible?** Print streams such as AFP, PCL, and PostScript describe where to draw text and lines, not what the text means. A PDF converted from one has positioned text with no headings, no table structure, and often no reading order, or is a page image with no text at all. Accessibility has to be introduced at the composition stage, where the engine still knows which text is a header cell and which is a transaction. #### Sources - eCFR: 28 CFR 35.201, Exceptions: https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H (The individualized, password-protected conventional electronic documents exception.) - ADA.gov: Fact Sheet on the Title II web and mobile rule: https://www.ada.gov/resources/2024-03-08-web-rule/ (The water or tax bill example and the statement of what the exceptions do not change.) - Federal Register, May 11, 2026: Extension of Compliance Dates, Accessibility of Web Content and Mobile Applications of Recipients of Departmental Financial Assistance (HHS): https://www.federalregister.gov/documents/2026/05/11/2026-09266/extension-of-compliance-dates-for-nondiscrimination-on-the-basis-of-disability-accessibility-of-web (The Section 504 rule mirrors the Title II rule's provisions.) - EUR-Lex: Directive (EU) 2019/882 (European Accessibility Act), Articles 2 and 4 and Annex I Section IV: https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng - veraPDF documentation: CLI validation: https://docs.verapdf.org/cli/validation/ ### Document accessibility laws by jurisdiction: the United States, United Kingdom, European Union, and Canada in one table Canonical URL: https://docaccessible.com/guides/document-accessibility-laws-by-jurisdiction One table of the laws that require accessible PDFs and documents in the US, UK, EU, and Canada: who is covered, the technical standard, the deadline, and how old documents are treated. Checked September 2026. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Every major regime names a WCAG level for documents: WCAG 2.1 AA in the ADA Title II rule, the HHS Section 504 rule, Colorado, and EN 301 549 V3.2.1; WCAG 2.0 AA in Section 508 and Ontario's AODA; WCAG 2.2 AA in the UK public sector regulations. - The next fixed dates are April 26, 2027 (ADA Title II, larger public entities), May 11, 2027 (HHS Section 504, recipients with 15 or more employees), and December 5, 2027 and 2028 (Canada's amended regulations); the EAA has applied since June 28, 2025 and Colorado's grace period ended July 1, 2025. - Old documents are treated similarly everywhere: excepted only if they predate a cutoff and are not used for a current service, form, or process. - None of these regimes names PDF/UA as the legal standard; PDF/UA is evidence toward the WCAG outcome, not a substitute for it. #### Questions answered **Which laws require PDFs to be accessible?** In the United States, the ADA Title II web rule (state and local government, WCAG 2.1 AA from April 26, 2027 or 2028), the HHS Section 504 rule (health providers, from May 11, 2027 or May 10, 2028), Section 508 (federal agencies), and Colorado's HB21-1110. In the UK, the Public Sector Bodies Accessibility Regulations 2018 (WCAG 2.2 AA). In the EU, the Web Accessibility Directive for the public sector and the European Accessibility Act from June 28, 2025. In Canada, the Accessible Canada Regulations (from December 5, 2027) and Ontario's AODA (WCAG 2.0 AA). **Is PDF/UA required by law?** None of the regimes checked for this guide names PDF/UA as the legal standard. They name WCAG at Level AA (version 2.0, 2.1, or 2.2 depending on the regime) or, in the EU, EN 301 549, which applies WCAG-derived requirements to documents. PDF/UA is a technical route to those outcomes and useful evidence, not a substitute. **Do old PDFs have to be made accessible?** Usually not, if they predate the regime's cutoff and are not used for a current service. The UK and EU public sector rules exempt documents published before September 23, 2018 unless needed for a service or active administrative process; the ADA Title II and HHS rules exempt preexisting documents unless currently used to apply for or participate in a programme; the EAA excludes office files published before June 28, 2025 from website requirements. Any document still used for a live process is in scope regardless of age. #### Sources - eCFR: 28 CFR Part 35, Subpart H, Web and Mobile Accessibility: https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H - Federal Register, May 11, 2026: HHS extension of compliance dates for web content and mobile applications: https://www.federalregister.gov/documents/2026/05/11/2026-09266/extension-of-compliance-dates-for-nondiscrimination-on-the-basis-of-disability-accessibility-of-web - U.S. Access Board: ICT Testing Baseline for Electronic Documents: https://ictbaseline.access-board.gov/document-baselines/ - Colorado OIT: FAQ, HB21-1110 Colorado Laws for Persons with Disabilities: https://oit.colorado.gov/standards-policies-guides/guide-to-accessible-web-services/faq-hb21-1110-colorado-laws-for-persons - Colorado General Assembly: HB24-1454: https://leg.colorado.gov/bills/hb24-1454 - GOV.UK: Understanding accessibility requirements for public sector bodies: https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps - EUR-Lex: Directive (EU) 2016/2102 (Web Accessibility Directive): https://eur-lex.europa.eu/eli/dir/2016/2102/oj - EUR-Lex: Commission Implementing Decision (EU) 2021/1339: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021D1339 - EUR-Lex: Directive (EU) 2019/882 (European Accessibility Act): https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng - Canada Gazette, Part II, December 17, 2025: Regulations Amending the Accessible Canada Regulations (SOR/2025-255): https://gazette.gc.ca/rp-pr/p2/2025/2025-12-17/html/sor-dors255-eng.html - Ontario.ca: How to make websites accessible: https://www.ontario.ca/page/how-make-websites-accessible ### The ADA Title II exceptions for documents: archived content, preexisting PDFs, password-protected files, and third-party content, read closely Canonical URL: https://docaccessible.com/guides/ada-title-ii-document-exceptions What 28 CFR 35.201 actually excepts from the WCAG 2.1 AA requirement, with the DOJ's own examples: archived web content, preexisting conventional electronic documents, third-party content, individualized password-protected documents, and social media posts. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - 28 CFR 35.201 lists five exceptions to the WCAG 2.1 AA requirement: archived web content, preexisting conventional electronic documents, content posted by a third party, individualized password-protected or otherwise secured documents, and preexisting social media posts. - "Conventional electronic documents" means web content in PDF, word processor, presentation, or spreadsheet formats, and nothing else. - The preexisting documents exception fails the moment a document is "currently used to apply for, gain access to, or participate in" a service, so every live form, application, and instruction sheet is in scope regardless of age. - Archived content must meet all four conditions (created before the compliance date, kept only for reference, research, or recordkeeping, stored in a clearly identified archive area, and unchanged since archiving); the DOJ warns that labelling content "archived" does not create the exception. - None of the exceptions removes the ADA's effective communication duty: a person who needs an excepted document in an accessible form must still be provided one. #### Questions answered **What counts as a "conventional electronic document" under the ADA Title II rule?** Web content or content in mobile apps that is in portable document formats, word processor file formats, presentation file formats, or spreadsheet file formats. That is the complete list in 28 CFR 35.104. PDFs, Word, PowerPoint, and Excel files published by a public entity are conventional electronic documents; HTML pages are not. **Are old PDFs exempt from the ADA Title II web rule?** Only if they were available before the entity's compliance date and are not currently used to apply for, gain access to, or participate in the entity's services, programs, or activities. A form, application, instruction sheet, or fee schedule still in use is in scope however old it is. Separately, content kept purely for reference in a clearly identified archive area and never changed since archiving is excepted as archived content. **Does the archived content exception apply if I put old documents in an "Archive" folder?** Not on its own. All four conditions must be met: the content predates the compliance date or reproduces pre-existing physical records, it is kept only for reference, research, or recordkeeping, it is stored in a clearly identified archive area, and it has not been changed since archiving. The DOJ states that entities may not circumvent their obligations merely by labelling content archived, and a document that provides current information, such as a current park map, does not qualify wherever it is stored. #### Sources - eCFR: 28 CFR Part 35, Subpart H, sections 35.200 to 35.205: https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H (The requirement, compliance dates as amended April 20, 2026, the five exceptions, conforming alternate versions, undue burden, and minimal impact.) - ADA.gov: Fact Sheet, New Rule on the Accessibility of Web Content and Mobile Apps Provided by State and Local Governments: https://www.ada.gov/resources/2024-03-08-web-rule/ (The four archived-content conditions, the examples quoted, and the section on what the exceptions do not change.) - eCFR: Appendix D to Part 35, Guidance to Revisions to ADA Title II Regulation on Accessibility of Web Information and Services: https://www.ecfr.gov/current/title-28/chapter-I/part-35/appendix-Appendix%20D%20to%20Part%2035 - Federal Register, April 20, 2026: Extension of Compliance Dates (DOJ interim final rule): https://www.federalregister.gov/documents/2026/04/20/2026-07663/extension-of-compliance-dates-for-nondiscrimination-on-the-basis-of-disability-accessibility-of-web ### The HHS Section 504 web and document accessibility rule for health providers: the dates moved to 2027 and 2028 Canonical URL: https://docaccessible.com/guides/hhs-section-504-web-document-accessibility HHS extended its Section 504 web content and mobile app deadlines by one year in May 2026. Who is covered, what WCAG 2.1 AA means for patient forms and documents, the new dates, and how the rule relates to Section 1557 and ADA Title II. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - HHS's May 9, 2024 Section 504 final rule added Subpart I, "Web, Mobile, and Kiosk Accessibility", requiring recipients of HHS financial assistance to make web content and mobile apps conform to WCAG 2.1 Level AA. - An interim final rule effective May 7, 2026 extended the compliance dates by one year: May 11, 2027 for recipients with fifteen or more employees and May 10, 2028 for recipients with fewer than fifteen. - The rule's provisions mirror the ADA Title II web rule, so its treatment of PDFs, forms, and other conventional electronic documents, and its exceptions, follow the same pattern. - The substantive requirements are unchanged, HHS has said it will consider further rulemaking, and the effective communication obligations that took effect on July 8, 2024 apply now. #### Questions answered **When is the HHS Section 504 web accessibility deadline for health providers?** May 11, 2027 for recipients of HHS financial assistance with fifteen or more employees, and May 10, 2028 for recipients with fewer than fifteen. HHS extended both dates by one year through an interim final rule effective May 7, 2026; they were originally May 11, 2026 and May 10, 2027. The technical standard is WCAG 2.1 Level AA and the requirements themselves did not change. **Does the HHS rule cover PDFs and patient forms?** Yes. The rule applies to web content a recipient provides or makes available, and its provisions mirror the ADA Title II rule, which treats PDFs, word processor, presentation, and spreadsheet files as conventional electronic documents. Forms and documents currently used to apply for, access, or participate in a programme are in scope regardless of when they were posted; genuinely archived material and individualized password-protected documents are excepted. **What is the difference between the Section 504 rule and Section 1557?** Section 1557 of the Affordable Care Act prohibits disability discrimination in health programmes and has its own 2024 HHS rule requiring accessible information and communication technology. The specific WCAG 2.1 AA standard and the 2027 and 2028 dates for web content and mobile apps are set out in HHS's Section 504 rule, 45 CFR part 84 Subpart I. HHS's Office for Civil Rights enforces both, and many entities are also covered by the ADA Title II rule. #### Sources - Federal Register, May 11, 2026: Extension of Compliance Dates for Nondiscrimination on the Basis of Disability; Accessibility of Web Content and Mobile Applications of Recipients of Departmental Financial Assistance (interim final rule): https://www.federalregister.gov/documents/2026/05/11/2026-09266/extension-of-compliance-dates-for-nondiscrimination-on-the-basis-of-disability-accessibility-of-web (Effective date, the new dates, the reasons, the statement that no substantive requirements change, and the plan for future rulemaking.) - HHS press release: HHS' Office for Civil Rights Extends Web and Mobile Accessibility Compliance Deadline: https://www.hhs.gov/press-room/hhs-extends-mobile-and-web-accessibility-deadline.html - Federal Register, May 9, 2024: Nondiscrimination on the Basis of Disability in Programs or Activities Receiving Federal Financial Assistance (89 FR 40066): https://www.federalregister.gov/documents/2024/05/09/2024-09237/nondiscrimination-on-the-basis-of-disability-in-programs-or-activities-receiving-federal-financial - eCFR: 28 CFR Part 35, Subpart H (ADA Title II web rule, mirrored by the HHS rule): https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H ### Colorado HB21-1110 and documents: what applies now that the July 1, 2025 grace period has ended Canonical URL: https://docaccessible.com/guides/colorado-hb21-1110-documents Colorado's digital accessibility law reaches PDFs and other documents published by state and local government. The OIT standards, the July 2024 and 2025 dates, the $3,500 statutory damages, and what a Colorado public body should do with its document backlog. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - HB21-1110, signed in 2021, made it discrimination under the Colorado Anti-Discrimination Act for a state or local government entity to fail to comply with the accessibility standards set by the Governor's Office of Information Technology (OIT) by July 1, 2024. - OIT's Technology Accessibility Rules (8 CCR 1501-11) set WCAG 2.1 Level AA as the standard, and OIT states the law reaches all public-facing and internal technology, explicitly including documents. - HB24-1454, approved May 24, 2024, extended immunity from liability to July 1, 2025 for entities that demonstrated good-faith efforts and posted quarterly progress reports; that grace period has ended. - Remedies include court orders, damages, attorney's fees, and a statutory fine of $3,500 payable to each plaintiff for each violation; liability for content lies with the entity that manages it. #### Questions answered **Does Colorado HB21-1110 apply to PDFs?** Yes. OIT states that the law and its accessibility standards apply to all public-facing and internal-facing technology provided or procured by a Colorado government entity, and its list explicitly includes documents alongside websites, applications, kiosks, digital signage, video, audio, and third-party tools. The technical standard in OIT's rules is WCAG 2.1 Level AA. **What is the deadline for Colorado HB21-1110?** Colorado government entities had to develop an accessibility plan by July 1, 2022 and fully comply with OIT's accessibility standards by July 1, 2024. HB24-1454 then extended immunity from liability to July 1, 2025 for entities demonstrating good-faith efforts and posting quarterly progress reports. That grace period has ended, so the obligation applies now. **What are the penalties under Colorado HB21-1110?** A person with a disability subjected to discrimination may bring a civil action, and the entity may face a court order requiring compliance, monetary damages, attorney's fees, or a statutory fine of $3,500 payable to each plaintiff for each violation. Liability for content lies with the entity that manages the content, and for a platform with the entity that manages the platform. #### Sources - Colorado OIT: FAQ, HB21-1110 Colorado Laws for Persons with Disabilities: https://oit.colorado.gov/standards-policies-guides/guide-to-accessible-web-services/faq-hb21-1110-colorado-laws-for-persons (The plan and compliance dates, the scope including documents, the penalties, and the allocation of liability, as quoted.) - Colorado General Assembly: HB24-1454, one-year extension for good-faith efforts: https://leg.colorado.gov/bills/hb24-1454 (Bill summary, approval and effective date of May 24, 2024.) - Colorado General Assembly: HB21-1110 as signed (PDF): https://content.leg.colorado.gov/sites/default/files/2021a_1110_signed.pdf - University of Colorado Denver: Colorado Law HB21-1110: https://www.ucdenver.edu/accessibility/digital-accessibility/colorado-law-hb21-1110 (A covered institution's summary of the OIT standard as WCAG 2.1 AA.) - eCFR: 28 CFR Part 35, Subpart H (ADA Title II web rule): https://www.ecfr.gov/current/title-28/chapter-I/part-35/subpart-H ### UK public sector PDFs: the 2018 regulations, the 23 September 2018 cutoff, WCAG 2.2, and the accessibility statement Canonical URL: https://docaccessible.com/guides/uk-public-sector-pdf-accessibility What the UK's 2018 public sector accessibility regulations require of PDFs: WCAG 2.2 AA, the pre-September 2018 exemption and its limit, who monitors and enforces, and GOV.UK's advice to publish HTML instead. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 came into force on 23 September 2018 and require public sector bodies to meet WCAG 2.2 AA and publish an accessibility statement. - PDFs and other documents published before 23 September 2018 are exempt unless users need them to use a service, for example a form; anything published since, or still needed for a service, is in scope. - The Government Digital Service monitors compliance on behalf of the Minister for the Cabinet Office and has monitored against WCAG 2.2 AA since October 2024; the Equality and Human Rights Commission and the Equality Commission for Northern Ireland enforce. - GOV.UK's guidance is to present information as HTML wherever a document can be avoided, and to make any remaining documents accessible or convert them. #### Questions answered **Do UK public sector PDFs published before 23 September 2018 have to be accessible?** Not unless users need them to use a service. GOV.UK lists PDFs and other documents published before 23 September 2018 among the exempt content, with the exception of documents needed to use a service, such as a form. Any document published or updated since that date, or still needed for a service whatever its date, must meet WCAG 2.2 AA or be made available in an accessible alternative. **Which WCAG version do the UK public sector regulations require?** GOV.UK's guidance states that public sector bodies must meet the WCAG 2.2 AA standard, and the Government Digital Service has monitored compliance against WCAG 2.2 AA since October 2024. Earlier guidance referred to WCAG 2.1 AA; the regulations themselves require sites and apps to be perceivable, operable, understandable, and robust. **Who enforces the UK accessibility regulations?** The Government Digital Service monitors public sector bodies' compliance on behalf of the Minister for the Cabinet Office. The Equality and Human Rights Commission enforces in England, Scotland, and Wales, and the Equality Commission for Northern Ireland enforces in Northern Ireland, using their powers under equality legislation. #### Sources - GOV.UK: Understanding accessibility requirements for public sector bodies: https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps (WCAG 2.2 AA, the document exemption wording, the accessibility statement, GDS monitoring, and the enforcement bodies.) - GOV.UK: Meet the requirements of equality and accessibility regulations: https://www.gov.uk/guidance/meet-the-requirements-of-equality-and-accessibility-regulations (The advice to present information as HTML where a document can be avoided.) - legislation.gov.uk: The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018: https://www.legislation.gov.uk/uksi/2018/852/contents/made ### EN 301 549 clause 10: what the European standard requires of non-web documents, and how the European Accessibility Act uses it Canonical URL: https://docaccessible.com/guides/en-301-549-documents-eaa Clause 10 of EN 301 549 applies WCAG-derived requirements to downloadable documents such as PDFs. What it covers, the version cited in EU law, the V4 draft moving to WCAG 2.2, and how the European Accessibility Act, in force since June 28, 2025, uses it. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Clause 10 of EN 301 549 applies to documents that are not web pages, are not embedded in web pages, or are provided with web pages as downloads, which covers PDFs, Office files, and e-books; documents embedded in a page fall under clause 9. - Its requirements mirror WCAG 2.1 Level A and AA success criteria adapted for documents, numbered 10.1.1.1 to 10.4.1.3, with "void" entries where a criterion does not apply, plus two document-specific clauses on caption positioning and audio description timing. - EN 301 549 V3.2.1 (March 2021) is the version cited in the Official Journal for the Web Accessibility Directive; a final draft V4.1.0 dated June 2026, moving to WCAG 2.2, is on ETSI's server but has no legal effect until cited. - The European Accessibility Act has applied since June 28, 2025 to listed products and services; its requirements are functional (Annex I), and a harmonised standard gives a presumption of conformity only once it is cited in the Official Journal for that Directive. #### Questions answered **What does EN 301 549 clause 10 apply to?** Clause 10 applies to documents that are not web pages, are not embedded in web pages, or are provided with web pages as downloads, which covers PDFs, Office files, e-books, and similar files that need a document reader. Documents embedded in a page and rendered with it fall under clause 9. The standard's notes add that the requirements also apply to documents protected by signatures, encryption, passwords, or watermarks. **Which version of EN 301 549 is legally in force?** EN 301 549 V3.2.1, published in March 2021, is the version cited in the Official Journal of the European Union by Commission Implementing Decision (EU) 2021/1339 for the Web Accessibility Directive, and its clauses 9, 10, and 11 correspond to WCAG 2.1 Level A and AA. A final draft V4.1.0 dated June 2026, expected to move to WCAG 2.2, has been published by ETSI but has no legal effect until it is cited in the Official Journal. **Does the European Accessibility Act require WCAG or EN 301 549 for documents?** The Act's requirements are functional and are set out in Annex I; it does not itself name WCAG or EN 301 549. It has applied since June 28, 2025 to listed products and services including e-books, consumer banking, and e-commerce, and excludes office file formats published before that date from its website content requirements. EN 301 549 is being revised to serve as a harmonised standard under the Act, which would give conforming documents a presumption of conformity once the version is cited in the Official Journal. #### Sources - ETSI: EN 301 549 V3.2.1 (2021-03), Accessibility requirements for ICT products and services (PDF): https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf (Clause 10.0 scope and notes, and the clause 10 requirement list, quoted above.) - ETSI: Final draft EN 301 549 V4.1.0 (2026-06) (PDF): https://www.etsi.org/deliver/etsi_en/301500_301599/301549/04.01.00_30/en_301549v040100va.pdf - EUR-Lex: Commission Implementing Decision (EU) 2021/1339 of 11 August 2021: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32021D1339 (Citation of EN 301 549 V3.2.1 as the harmonised standard under Directive (EU) 2016/2102.) - EUR-Lex: Directive (EU) 2019/882 (European Accessibility Act): https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng (Articles 2, 4, 31, and 32 and Annex I, as quoted.) - W3C: EPUB Accessibility, EU Accessibility Act Mapping (Group Note, August 28, 2025): https://www.w3.org/TR/epub-a11y-eaa-mapping/ ### The European Accessibility Act and e-books: the six Annex I requirements, EPUB Accessibility 1.1, and what a PDF e-book has to do Canonical URL: https://docaccessible.com/guides/eaa-ebooks-epub-pdf E-books are in scope of the European Accessibility Act since June 28, 2025. The six e-book requirements in Annex I verbatim, how W3C maps them to EPUB Accessibility 1.1, the exemptions and transition period, and what publishers with PDF-only titles need to do. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Directive (EU) 2019/882 applies to e-readers placed on the market and to "e-books and dedicated software" provided to consumers after June 28, 2025. - Annex I Section IV(f) sets six e-book requirements: synchronised text and audio where audio exists, files that do not prevent assistive technology from operating, access to content, navigation, structure, and flexible presentation, alternative renditions and AT interoperability, discoverability through accessibility metadata, and DRM that does not block accessibility features. - A W3C Group Note of August 28, 2025 maps each requirement to EPUB Accessibility 1.1 (a W3C Recommendation since October 2024) and WCAG, giving EPUB a documented conformance path; no equivalent mapping exists for PDF. - Microenterprises providing services are exempt, and Article 32 allows service contracts agreed before June 28, 2025 to run to expiry for up to five years, so the widely cited backlist date is June 28, 2030; new titles are in scope now. #### Questions answered **Does the European Accessibility Act apply to e-books?** Yes. Article 2(2)(e) of Directive (EU) 2019/882 lists e-books and dedicated software among the services in scope when provided to consumers after June 28, 2025, and Article 2(1)(e) lists e-readers among in-scope products. Annex I Section IV(f) sets six requirements for e-books, covering synchronised audio, compatibility with assistive technology, navigation and structure, alternative renditions, accessibility metadata, and DRM that does not block accessibility features. **Can a PDF e-book comply with the European Accessibility Act?** The Act is format-neutral, so a PDF e-book must meet the same six Annex I requirements: a tagged, navigable structure that assistive technology can use, flexible presentation, accessibility metadata, and DRM that does not block accessibility features. EPUB has a W3C-published mapping to those requirements through EPUB Accessibility 1.1; PDF has none, and its fixed layout makes flexible presentation hard, so EPUB is the recommended format for new titles and PDF editions should be tagged to PDF/UA and described in metadata. **What is the 2030 date for e-books under the EAA?** Article 32 provides a transitional period ending June 28, 2030 during which service providers may continue using products lawfully used before June 28, 2025, and allows service contracts agreed before that date to run without alteration until they expire, for at most five years. It is a transition for existing arrangements, not a deferral: e-books provided to consumers after June 28, 2025 are in scope now. #### Sources - EUR-Lex: Directive (EU) 2019/882 (European Accessibility Act), Articles 2, 4, 31, 32 and Annex I Section IV: https://eur-lex.europa.eu/eli/dir/2019/882/oj/eng (Scope, dates, the microenterprise exemption, the transitional measures, and the six e-book requirements quoted verbatim.) - W3C: EPUB Accessibility, EU Accessibility Act Mapping (Group Note, August 28, 2025): https://www.w3.org/TR/epub-a11y-eaa-mapping/ (The requirement-by-requirement mapping to EPUB Accessibility 1.1 and WCAG, and the fixed-layout limitation.) - W3C: EPUB Accessibility 1.1 (Recommendation): https://www.w3.org/TR/epub-a11y-11/ ### Document accessibility in Canada: the December 2025 Accessible Canada Regulations and Ontario's AODA Canonical URL: https://docaccessible.com/guides/canada-document-accessibility-aca-aoda Canada's amended Accessible Canada Regulations set December 2027 and 2028 dates for web pages, apps, and non-web documents against CAN/ASC-EN 301 549:2024. Who is covered, the exemptions, and how Ontario's AODA (WCAG 2.0 AA) applies to documents. - Category: Laws and deadlines - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - Regulations Amending the Accessible Canada Regulations (SOR/2025-255), registered December 5, 2025 and published December 17, 2025, require federally regulated entities' newly created or updated web pages, mobile applications, and non-web documents to conform, to the extent feasible, to CAN/ASC-EN 301 549:2024. - Web pages must conform from December 5, 2027 for the federal public sector and from December 5, 2028 for private-sector entities with 100 or more employees; non-web documents and mobile apps from December 5, 2028 for the public sector and businesses with 500 or more employees. - CAN/ASC-EN 301 549:2024 adopts EN 301 549 V3.2.1, so the document requirements are its clause 10, corresponding to WCAG 2.1 Level AA. - Ontario's AODA has required designated public sector organisations and organisations with 50 or more employees to meet WCAG 2.0 AA (except 1.2.4 and 1.2.5) for websites and web content published after January 1, 2012 since January 1, 2021. #### Questions answered **When do Canadian federal organizations have to make documents accessible?** Under the Regulations Amending the Accessible Canada Regulations registered December 5, 2025, the federal public sector must ensure new or updated web pages conform to CAN/ASC-EN 301 549:2024 from December 5, 2027, and new or updated non-web documents and mobile applications from December 5, 2028. Federally regulated private-sector entities with 500 or more employees have the December 5, 2028 date for web pages, apps, and documents; those with 100 to 499 employees have December 5, 2028 for web pages only; smaller businesses are exempt. **What standard does CAN/ASC-EN 301 549:2024 require for PDFs?** CAN/ASC-EN 301 549:2024 is Accessibility Standards Canada's adoption of the European standard EN 301 549 V3.2.1. Its clause 10 applies WCAG 2.1 Level A and AA success criteria to non-web documents such as PDFs: text alternatives, structure and reading order, contrast, keyboard access, a document title, focus order, link purpose, document language and language of parts, form labels and errors, and name-role-value for fields. **Does the AODA require PDFs to be accessible?** Yes for organisations it covers. Since January 1, 2021, designated public sector organisations and businesses or non-profits with 50 or more employees in Ontario must make public websites and web content published after January 1, 2012 conform to WCAG 2.0 Level AA, except criteria 1.2.4 and 1.2.5. Where conformance is not practicable, the organisation must explain why the content is unconvertible and provide a summary on request, and it must work with anyone who requests an accessible format. #### Sources - Canada Gazette, Part II, Volume 159, Number 26 (December 17, 2025): Regulations Amending the Accessible Canada Regulations (SOR/2025-255): https://gazette.gc.ca/rp-pr/p2/2025/2025-12-17/html/sor-dors255-eng.html (Covered entities, the standard incorporated by reference, the staged dates, the definitions of update and feasibility, and the exemptions.) - Justice Laws Website: Accessible Canada Regulations (SOR/2021-241): https://laws-lois.justice.gc.ca/eng/regulations/sor-2021-241/index.html - Accessibility Standards Canada: CAN/ASC-EN 301 549:2024, Accessibility requirements for ICT products and services (PDF): https://accessible.canada.ca/sites/default/files/2025-06/canasc-en3015492024_accessibilityrequirements-for-ict-products-and-services.pdf - Ontario.ca: How to make websites accessible: https://www.ontario.ca/page/how-make-websites-accessible (Who must comply, WCAG 2.0 AA and the two excluded criteria, the January 1, 2012 content date, and the unconvertible-content and accessible-format duties.) - Ontario e-Laws: O. Reg. 191/11, Integrated Accessibility Standards: https://www.ontario.ca/laws/regulation/110191 ### VPAT and ACR explained: versions, editions, conformance levels, and how to read one before you buy Canonical URL: https://docaccessible.com/guides/vpat-acr-explained What a VPAT is, what an Accessibility Conformance Report is, the current VPAT 2.5 template and its four editions, the conformance levels, why an ACR is not a certification, and the questions to ask when a vendor sends one. - Category: Testing and evidence - Published: 2026-09-02. Last reviewed: 2026-09-02. #### Key points - A VPAT is a blank template published by the Information Technology Industry Council (ITI); a completed one for a specific product is an Accessibility Conformance Report (ACR). Vendors often say "VPAT" when they mean the ACR. - The current template is VPAT 2.5Rev (April 2025), in four editions: 508 (Revised Section 508), EU (EN 301 549), WCAG (WCAG 2.0, 2.1, and 2.2), and INT, which covers all three. - Each criterion is reported as Supports, Partially Supports, Does Not Support, or Not Applicable, with a remarks column explaining the finding. - An ACR is the vendor's own report and ITI does not review or certify it; read the template version, product version, date, evaluation methods, and remarks before relying on it. - A VPAT describes a product or service, not a document; documents are evidenced by test records against a baseline or checklist. #### Questions answered **What is the difference between a VPAT and an ACR?** A VPAT (Voluntary Product Accessibility Template) is the blank template published by the Information Technology Industry Council, with a structured list of accessibility criteria and empty columns. An ACR (Accessibility Conformance Report) is a VPAT completed for a specific product version, recording a conformance level and remarks for each criterion. When a buyer asks for a VPAT they almost always mean the completed ACR. **What are the VPAT 2.5 editions?** VPAT 2.5, currently at revision 2.5Rev dated April 2025, comes in four editions: 508 for the Revised Section 508 Standards, EU for EN 301 549, WCAG for WCAG 2.0, 2.1, and 2.2, and INT, which incorporates all three. Vendors choose the edition matching the standards their buyers require; the INT edition covers several markets at once. **Is a VPAT a certification?** No. A completed ACR is the vendor's report of its own testing, using one of four conformance levels (Supports, Partially Supports, Does Not Support, Not Applicable) with remarks. ITI publishes the template but does not review or certify the conclusions. Buyers should check the template version, product version, date, and evaluation methods, read the remarks, and ask for the underlying test evidence. #### Sources - ITI: VPAT (Voluntary Product Accessibility Template): https://www.itic.org/policy/accessibility/vpat (The current version 2.5Rev (April 2025), the four editions and their standards, the conformance levels, the definition of an ACR, and the trademark requirements.) - Section508.gov: How to Create an Accessibility Conformance Report Using a VPAT: https://www.section508.gov/sell/how-to-create-acr-with-vpat/ - U.S. Access Board: ICT Testing Baseline for Electronic Documents: https://ictbaseline.access-board.gov/document-baselines/ (The document-level evidence that stands in for a VPAT where documents rather than products are being procured.) ## 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): Six free browser tools: website PDF scanner, PDF-to-HTML converter, accessibility checker, tag viewer, auto-tagger, and scanned-PDF text recovery. - [Free website PDF scanner](https://docaccessible.com/tools/website-pdf-scanner): Enter a domain and list every public PDF the site links to, where each is linked from, and automated checks on the most-linked files. No script, no account. - [Free PDF to HTML converter](https://docaccessible.com/tools/pdf-to-html): Convert the first ten pages of a PDF into a visual-first semantic transcript and compare it with the source. - [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 tag editor and auto-tagger](https://docaccessible.com/tools/pdf-auto-tagger): Auto-tag an eligible born-digital PDF, inspect the exact candidate tag tree, safely correct paragraph and heading roles, and download the reverified result. - [Free scanned-PDF accessibility tool](https://docaccessible.com/tools/make-scanned-pdf-accessible): Detect scanned and OCR-derived pages and route them to reviewed OCR or specialist remediation instead of automatic tagging. - [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. - [Document accessibility answers](https://docaccessible.com/answers): Direct answers to the most common questions: manual remediation cost per page, plan pricing, hosted HTML versus tagged PDF, WCAG and PDF/UA scope, and ADA Title II deadlines. - [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. - [Which apps export tagged PDFs? A 2026 matrix](https://docaccessible.com/guides/which-apps-export-tagged-pdfs): A vendor-sourced matrix of which authoring tools write PDF tags on export, which setting turns them on, and where each one still needs a manual check. - [Google Docs to accessible PDF: what the export tags](https://docaccessible.com/guides/google-docs-to-accessible-pdf): Google Docs has exported tagged PDFs since December 2024. What the tagging covers, how to prepare the document, and the checks to run before you publish. - [Word to PDF: Save As keeps tags, Print loses them](https://docaccessible.com/guides/word-save-as-pdf-vs-print-to-pdf): The exact Word, Excel, and PowerPoint settings on Windows and macOS that produce a tagged PDF, why printing to PDF produces an untagged one, and what to fix in the source first. - [Canva PDF accessibility: settings that keep tags](https://docaccessible.com/guides/canva-pdf-accessibility): How to export a Canva design as a tagged PDF, set reading order and heading semantics, add alt text and a language, and where Canva says the result may still fail. - [Accessible PDFs from LaTeX in 2026](https://docaccessible.com/guides/latex-accessible-pdf): How to produce tagged, PDF/UA-2 targeted output from LaTeX with \DocumentMetadata, which engine to use, how to add alt text and tagged math, and where package support still limits results. - [Tagged PDFs from HTML: Chrome, Puppeteer, Prince](https://docaccessible.com/guides/tagged-pdf-from-html-chrome-puppeteer-prince): For developers generating PDFs from HTML: which engines write tags, the flags that control them, why the HTML's semantics decide the result, and how to validate against PDF/UA. - [PDF/UA-2 explained: what ISO 14289-2 changes](https://docaccessible.com/guides/pdf-ua-2-explained): PDF/UA-2 (ISO 14289-2:2024) is the accessibility standard for PDF 2.0 files. What it adds over PDF/UA-1, its relationship to WTPDF, and which tools produce or validate it today. - [The Matterhorn Protocol explained](https://docaccessible.com/guides/matterhorn-protocol-explained): What the Matterhorn Protocol is, how its 31 checkpoints and 136 failure conditions test PDF/UA-1, which ones a machine can decide, and how to read a checker report built on it. - [PDF/A vs PDF/UA: archival is not accessible](https://docaccessible.com/guides/pdf-a-vs-pdf-ua): PDF/A preserves a document for the long term; PDF/UA makes it usable with assistive technology. What each level guarantees, why PDF/A-1a is not accessibility, and how to produce files that satisfy both. - [The 5 document-level PDF settings checkers flag](https://docaccessible.com/guides/pdf-document-settings-checkers-flag): The document-level PDF settings that fail accessibility checks most often: title and DisplayDocTitle, language, bookmarks, tab order, and the permission that lets screen readers read text. Where each lives and which rule tests it. - [Language tagging in PDFs, including multilingual](https://docaccessible.com/guides/pdf-language-tagging-multilingual): How to declare a PDF's language and mark passages in other languages so screen readers pronounce them correctly, which WCAG techniques and PDF/UA conditions apply, and how to handle bilingual documents. - [Accessible PDF forms: AcroForm vs XFA and WCAG](https://docaccessible.com/guides/accessible-pdf-forms-acroform-xfa): Why XFA forms fail accessibility and archiving, how AcroForm fields get an accessible name through tooltips, the WCAG PDF techniques for forms, and when an HTML form is the better answer. - [Acrobat accessibility checker vs PAC, explained](https://docaccessible.com/guides/acrobat-checker-vs-pac): Why a PDF can pass Adobe Acrobat's accessibility checker and fail PAC, what each tool actually tests, how to read their reports, and what neither can decide. - [How to test a PDF with a screen reader](https://docaccessible.com/guides/test-pdf-with-screen-reader): A repeatable screen reader test for PDFs with NVDA, JAWS, or VoiceOver: which viewer to open the file in, the keystrokes to use, what to listen for, and independent data on which viewers expose tags. - [Section 508 document testing: the Baseline explained](https://docaccessible.com/guides/section-508-document-testing-baseline): The Section 508 ICT Testing Baseline for Electronic Documents (version 1.0, September 2024): its 24 tests, who wrote it, how it relates to the Revised 508 Standards and WCAG, and how to use it outside government. - [Alt text for charts and graphs in PDFs](https://docaccessible.com/guides/alt-text-charts-graphs-pdf): How to write text alternatives for charts, graphs, and infographics in PDFs using the two-part pattern W3C recommends: a short alt on the figure and a long description or data table in the document. - [Accessible maps, floor plans, and drawings in PDFs](https://docaccessible.com/guides/accessible-maps-floor-plans-drawings): Spatial graphics cannot be made accessible with a sentence of alt text. How to provide equivalent access to maps, site plans, floor plans, and technical drawings, and what the law says about them. - [E-signatures and accessible PDFs: the right order](https://docaccessible.com/guides/e-signatures-and-tagged-pdfs): How signing platforms handle PDF tags, what Adobe and Docusign document about accessible envelopes, why a digital signature freezes the file, and the order of operations that keeps signed documents accessible. - [Accessible statements and notices at scale](https://docaccessible.com/guides/accessible-statements-notices-at-scale): How to make high-volume transactional documents (statements, bills, explanations of benefits, notices) accessible by fixing the template and composition pipeline, what the law expects, and how to validate by sample. - [Document accessibility laws by jurisdiction (2026)](https://docaccessible.com/guides/document-accessibility-laws-by-jurisdiction): One table of the laws that require accessible PDFs and documents in the US, UK, EU, and Canada: who is covered, the technical standard, the deadline, and how old documents are treated. Checked September 2026. - [ADA Title II exceptions for PDFs and documents](https://docaccessible.com/guides/ada-title-ii-document-exceptions): What 28 CFR 35.201 actually excepts from the WCAG 2.1 AA requirement, with the DOJ's own examples: archived web content, preexisting conventional electronic documents, third-party content, individualized password-protected documents, and social media posts. - [HHS Section 504 web accessibility rule: 2027 and 2028](https://docaccessible.com/guides/hhs-section-504-web-document-accessibility): HHS extended its Section 504 web content and mobile app deadlines by one year in May 2026. Who is covered, what WCAG 2.1 AA means for patient forms and documents, the new dates, and how the rule relates to Section 1557 and ADA Title II. - [Colorado HB21-1110 and documents after July 2025](https://docaccessible.com/guides/colorado-hb21-1110-documents): Colorado's digital accessibility law reaches PDFs and other documents published by state and local government. The OIT standards, the July 2024 and 2025 dates, the $3,500 statutory damages, and what a Colorado public body should do with its document backlog. - [UK public sector PDF accessibility rules explained](https://docaccessible.com/guides/uk-public-sector-pdf-accessibility): What the UK's 2018 public sector accessibility regulations require of PDFs: WCAG 2.2 AA, the pre-September 2018 exemption and its limit, who monitors and enforces, and GOV.UK's advice to publish HTML instead. - [EN 301 549 clause 10 for documents and the EAA](https://docaccessible.com/guides/en-301-549-documents-eaa): Clause 10 of EN 301 549 applies WCAG-derived requirements to downloadable documents such as PDFs. What it covers, the version cited in EU law, the V4 draft moving to WCAG 2.2, and how the European Accessibility Act, in force since June 28, 2025, uses it. - [The European Accessibility Act and e-books](https://docaccessible.com/guides/eaa-ebooks-epub-pdf): E-books are in scope of the European Accessibility Act since June 28, 2025. The six e-book requirements in Annex I verbatim, how W3C maps them to EPUB Accessibility 1.1, the exemptions and transition period, and what publishers with PDF-only titles need to do. - [Canada document accessibility: ACA regulations and AODA](https://docaccessible.com/guides/canada-document-accessibility-aca-aoda): Canada's amended Accessible Canada Regulations set December 2027 and 2028 dates for web pages, apps, and non-web documents against CAN/ASC-EN 301 549:2024. Who is covered, the exemptions, and how Ontario's AODA (WCAG 2.0 AA) applies to documents. - [VPAT and ACR explained: how to read one](https://docaccessible.com/guides/vpat-acr-explained): What a VPAT is, what an Accessibility Conformance Report is, the current VPAT 2.5 template and its four editions, the conformance levels, why an ACR is not a certification, and the questions to ask when a vendor sends one. - [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.