PDF Accessibility Compliance Guide 2026: ADA, Section 508, and WCAG 2.1

<p>PDF accessibility is evaluated against a specific set of technical requirements derived from WCAG 2.1 and the PDF/UA-1 standard (ISO 14289-1). Understanding each requirement precisely prevents the common mistake of checking superficial boxes while missing structural issues that render documents practically inaccessible despite having some accessibility features present.</p><p><strong>1. Document tags and structure (most fundamental requirement).</strong> A tagged PDF contains an invisible logical structure tree that defines every element as a specific type: paragraph, heading level 1-6, list item, table cell, figure, or form field. Screen readers (JAWS, NVDA, VoiceOver) read this structure tree, not the visual layout, to present content to users. A PDF without tags is completely inaccessible — a screen reader announces only "PDF document" with no navigable content. Adding tags retroactively to an existing PDF is possible but technically demanding; creating tagged PDFs from source documents is far more efficient. Word documents with proper heading styles export as tagged PDFs automatically via /en/word-to-pdf. InDesign with accessibility features enabled exports tagged PDFs. Scanned PDFs and most PDFs created by printing to PDF (Ctrl+P → Save as PDF) produce untagged output and require post-creation tagging with professional tools like Adobe Acrobat Pro.</p><p><strong>2. Reading order.</strong> The logical reading order is the sequence in which content should be encountered by a screen reader, which may differ substantially from visual left-to-right, top-to-bottom reading. Multi-column layouts, sidebars, callout boxes, headers, and footers all create ambiguous reading orders if not explicitly structured. A two-column article where the screen reader reads all of column 1 then all of column 2 is correctly ordered. A document where the screen reader alternates between left column and right column line-by-line produces incomprehensible content even though it looks perfectly organized visually. Reading order is set through the tag tree structure and requires professional PDF editing software (Acrobat Pro, Foxit PDF Editor) to remediate correctly in complex layouts.</p><p><strong>3. Alternative text for images, charts, and figures.</strong> Every image that conveys information must have alternative text (alt text) describing its content to users who cannot see it. Purely decorative images (background textures, divider lines, ornamental icons) should be marked as artifacts so screen readers skip them. Alt text quality requirements from WCAG 2.1: text must convey the same information as the image, must not say "image of" or "picture of" (redundant), and must be concise (typically 125 characters maximum for simple images, longer allowed for complex data visualizations). A chart showing 2023 revenue by product line needs alt text that describes the key data insight ("Bar chart showing Product A at $2.3M, Product B at $1.8M, Product C at $890K in 2023") rather than simply "revenue chart."</p><p><strong>4. Color contrast ratios.</strong> WCAG 2.1 Level AA requires a minimum contrast ratio of 4.5:1 between text color and background color for normal text (under 18pt or 14pt bold), and 3:1 for large text (18pt+ or 14pt+ bold). This requirement applies to text rendered inside images as well as live text. Common failures: light gray text on white backgrounds (1.8:1 — fails badly), medium blue on white (3.2:1 — fails for normal text), and yellow text on white (1.07:1 — nearly invisible). The WebAIM Contrast Checker at webaim.org/resources/contrastchecker calculates ratios for any color pair. Most professional document color schemes pass when designed correctly, but heavily branded documents that use company color palettes often fail because brand colors were developed for visual aesthetic rather than accessibility compliance.</p><p><strong>5. Document title and language.</strong> Every accessible PDF must declare its document title (a human-readable title, not the file name) in Document Properties, and must declare its primary language using an ISO 639-1 language code ("en" for English, "es" for Spanish, "fr" for French). Language declaration enables screen readers to use the correct speech synthesis engine — a document marked as French will be read with French phonology, producing correct pronunciation for French words. Without a language declaration, screen readers default to the user's system language, which may mispronounce words dramatically and confuse the listener.</p><p><strong>6. Accessible form fields (for fillable PDFs).</strong> Interactive PDF forms require that every form field have an accessible name (a label that screen readers announce when the field receives focus), that the tab order through form fields follows a logical sequence, and that required fields are explicitly identified as required in a way that does not rely on color alone. A form where required fields are marked only by a red border fails accessibility requirements for two reasons: color-blind users cannot detect the red distinction, and screen readers do not announce visual border styles. Required fields must include text like "(required)" in the field label or use the required property in the form field attributes.</p><p><strong>7. No flashing content and no time limits without extension.</strong> PDFs should not contain animated content that flashes more than 3 times per second (which can trigger seizures in photosensitive users), and interactive forms with time limits must offer users the ability to turn off, adjust, or extend the timer. These requirements apply primarily to interactive PDFs with embedded JavaScript, which are rare but appear in some government e-filing portals and educational assessment systems.</p>

1. 1Step 1: Check whether your PDF is tagged by opening it in Adobe Reader and going to File → Properties → Description tab. If 'Tagged PDF: Yes' appears, you have the basic structural requirement. If it says 'No', the document is untagged and requires remediation before it can be considered accessible.
2. 2Step 2: Run the PDF through Adobe Acrobat Pro's accessibility checker (Tools → Accessibility → Full Check) or the free PAC 2021 tool (pdfua.foundation/pac) to identify specific compliance failures. Note which elements fail — tags, reading order, alt text, or color contrast — to prioritize remediation.
3. 3Step 3: Check contrast ratios for all text and background color combinations using webaim.org/resources/contrastchecker. Input your text color and background color hex values to get the exact contrast ratio. Flag any combination below 4.5:1 for normal text or 3:1 for large text.
4. 4Step 4: Verify the document title and language in Document Properties (Ctrl+D in Adobe Reader). The Title field should contain a human-readable title (not the file name), and the Language field should show the correct ISO language code.

<p>Compliance audits and automated accessibility scanners consistently identify the same failures across government agencies, healthcare organizations, universities, and private sector companies. Understanding these patterns allows you to prevent them at the document creation stage rather than paying for expensive remediation after the fact.</p><p><strong>Failure 1: Scanned image-only PDFs (most prevalent, highest severity).</strong> A PDF created by scanning a physical document — or by printing a document to a physical printer and rescanning it — contains only raster images with no text data. Screen readers encounter a blank document. This failure affects an estimated 35–45% of PDFs on government and institutional websites, based on automated scans conducted by accessibility advocacy organizations in 2024. The fix: run scanned PDFs through OCR to add a text layer. /en/ocr applies Tesseract OCR to add searchable, screen-reader-accessible text to scanned documents. The OCR accuracy depends on scan quality: clear 300 DPI black-and-white scans of clean originals achieve 98–99% character accuracy; low-quality 72 DPI scans of documents with degraded print achieve 80–85% accuracy and require manual correction for compliance-critical content.</p><p><strong>Failure 2: Untagged PDFs from print-to-PDF workflows (very common in organizations without PDF authoring training).</strong> When users create PDFs by using their operating system's print dialog (Ctrl+P → Save as PDF), the resulting file lacks the logical structure tree required for accessibility. This creates a visually correct document that is structurally invisible to screen readers. The prevention is simple: always create PDFs from source documents using dedicated export functions (File → Export to PDF or File → Save As PDF in the original application) rather than via the print dialog. Export functions preserve document structure from heading styles, paragraph types, and list formatting. Print dialogs flatten everything to a visual representation with no semantic information.</p><p><strong>Failure 3: Missing or inadequate alt text on images (very common in all sectors).</strong> Studies of accessible PDF remediations consistently find that 60–70% of images in typical business PDFs have either no alt text or alt text consisting only of the file name ("image001.jpg") which conveys nothing. For documents created in Word, alt text is added by right-clicking images and selecting Edit Alt Text before exporting to PDF — this alt text transfers directly into the exported PDF's tag structure. For existing PDFs without alt text, Adobe Acrobat Pro's tag editor allows adding alt text to figure elements in the tag tree, but this process requires professional software and significant time investment for image-heavy documents.</p><p><strong>Failure 4: Complex tables without proper header row markup.</strong> Data tables in PDFs are only accessible when the header row is tagged as table headers (TH) rather than regular table data cells (TD). Without this distinction, screen readers cannot establish the relationship between data cells and their column or row headers, making tabular data effectively meaningless to screen reader users who cannot see the visual position relationship. A table of quarterly revenue figures where the headers are not tagged is read as a string of numbers with no column context. Table header accessibility must be set during document creation — Word tables with properly applied header row formatting export with correct TH/TD structure, but tables created using custom borders and merged cells often export incorrectly.</p><p><strong>Failure 5: PDFs created from PowerPoint slides without accessibility remediation.</strong> PowerPoint-to-PDF conversion preserves accessibility properties from the original slide deck, but slide decks are frequently created without accessibility in mind. Slides with text boxes placed in reading-order-violating positions, images without alt text, and charts with color-only data differentiation all produce non-compliant PDFs when exported. The minimum remediation for a PowerPoint-derived PDF: add alt text to every image and chart in the original PowerPoint (right-click → Edit Alt Text), ensure all text boxes follow left-to-right, top-to-bottom placement order, and verify that charts convey all data through text as well as color (label data points directly rather than relying on a color-coded legend).</p><p>For organizations processing large volumes of documents for compliance, our guide on <a href="/en/blog/best-pdf-tools-for-small-teams-2026">best PDF tools for small teams</a> covers document workflow management tools that can integrate accessibility checks into the standard review process before documents are published externally.</p>

1. 1Step 1: Run every new PDF through PAC 2021 (free download from pdfua.foundation/pac) before publishing externally. PAC checks for PDF/UA conformance and identifies tag, alt text, reading order, and language failures in a detailed report — faster than manual review for standard documents.
2. 2Step 2: For scanned PDFs, run through /en/ocr to add a text layer as a first remediation step. This converts the image-only document into a document with searchable text. For compliance-critical content, manually verify OCR accuracy by comparing the extracted text to the original document.
3. 3Step 3: For Word-originated PDFs with tag failures, return to the source DOCX file and correct the document structure: apply proper Heading 1/2/3 styles (not manual bold and font size changes), ensure all images have alt text via right-click → Edit Alt Text, then re-export using File → Save As → PDF rather than print-to-PDF.
4. 4Step 4: For PDFs where returning to the source is not possible, use Adobe Acrobat Pro's accessibility remediation tools (Tools → Accessibility → Autotag Document, then manually correct the resulting tag tree). The free alternative — exporting to Word via /en/pdf-to-word, correcting the document structure in Word, then re-exporting to PDF — works for text-heavy documents but degrades complex layouts.

<p>PDF accessibility compliance is no longer purely voluntary for most organizations. The legal landscape in 2026 includes mandatory deadlines, active enforcement, and significant settlement exposure for organizations that have not addressed known accessibility barriers. Understanding which laws apply to your organization determines your compliance timeline and the minimum technical standard you must meet.</p><p><strong>ADA Title II (State and local government):</strong> The DOJ's final rule published April 24, 2024 (effective June 24, 2024) requires all state and local government entities to meet WCAG 2.1 Level AA for their websites and digital content, including PDFs. Large entities (population over 50,000) must comply by April 24, 2026. Small entities (population under 50,000) must comply by April 26, 2027. PDFs linked from or embedded in government websites are explicitly covered. This applies to every department, agency, school district, and public institution at the state, county, and municipal level. The DOJ has authority to investigate complaints and initiate compliance reviews; private plaintiffs can also sue under ADA Title II for declaratory and injunctive relief.</p><p><strong>ADA Title III (Private sector businesses and nonprofits):</strong> Title III prohibits discrimination in places of public accommodation, which federal courts and the DOJ have consistently interpreted to include websites and digital documents since 2019. There is no specific federal deadline for Title III compliance — the requirement is ongoing and immediate. Private plaintiffs can file suit without prior agency complaint, and demand letters from accessibility law firms have become an industry in their own right. Organizations with revenue above $10 million and significant web presence have the highest exposure. Settlement agreements typically require WCAG 2.1 Level AA compliance for all public-facing web content including PDFs, plus a monitoring period of 2–3 years with quarterly accessibility testing reports.</p><p><strong>Section 508 (Federal agencies and contractors):</strong> Section 508 of the Rehabilitation Act requires all electronic and information technology developed, procured, maintained, or used by federal agencies to be accessible. This applies to PDFs created, published, or used by federal agencies and to organizations that provide PDF content to federal agencies under contract. The technical standard for Section 508 compliance incorporates WCAG 2.1 Level AA by reference since 2018 (the Section 508 ICT Standards Refresh). Federal procurement requirements mean that contractors providing document management systems, content management systems, or document repositories to federal agencies must ensure PDF outputs from those systems meet Section 508 standards.</p><p><strong>EU Web Accessibility Directive and EAA:</strong> In the European Union, the Web Accessibility Directive (2016/2102) requires public sector bodies to make their websites and mobile apps accessible to WCAG 2.1 Level AA, including all PDFs linked from those sites. The European Accessibility Act (EAA), which came into force for member states on June 28, 2025, extends accessibility requirements to private sector organizations offering products and services including digital content and documents. Organizations serving EU markets should treat WCAG 2.1 Level AA as the baseline compliance standard for any PDF intended for public distribution.</p><p><strong>WCAG 3.0 outlook for 2026–2027:</strong> The W3C is developing WCAG 3.0, currently in draft status (last published working draft: October 2023). WCAG 3.0 will not replace WCAG 2.1 immediately — regulatory bodies will continue referencing WCAG 2.1 Level AA for several years after WCAG 3.0 reaches recommendation status. Organizations should achieve WCAG 2.1 Level AA compliance now rather than waiting for WCAG 3.0 finalization. For teams needing to manage accessible documents alongside remote collaboration, our guide on <a href="/en/blog/best-pdf-tools-for-remote-work-2026">best PDF tools for remote work 2026</a> covers document management workflows that support accessibility review steps within distributed team processes.</p>

1. 1Step 1: Determine which laws apply to your organization. Government entities → ADA Title II (deadline April 2026 for large entities). Federal agencies and contractors → Section 508 (immediate, ongoing). Private businesses → ADA Title III (ongoing, no deadline). EU public sector → Web Accessibility Directive. EU private sector → European Accessibility Act (effective June 2025).
2. 2Step 2: Conduct an inventory of all PDFs published on your external website or distributed publicly. Categorize by creation date and method — PDFs created from Word with proper styles are lower remediation risk; scanned PDFs and print-to-PDF outputs are high risk.
3. 3Step 3: Prioritize remediation by impact: fix high-traffic PDFs (annual reports, application forms, key policy documents) first. Scanned PDFs need OCR plus professional tagging. Word-originated PDFs need source document correction and re-export.
4. 4Step 4: Establish an ongoing workflow that prevents new accessibility failures: create a PDF accessibility checklist for your document creation process, train staff on Word heading styles and alt text requirements, and run automated accessibility checks (PAC or Acrobat) before every external PDF publication.

<p>Accessibility built into the source document is 10x faster and 20x cheaper than post-creation remediation. A PDF exported from a properly structured Word document can be 90% accessible with zero additional effort; the same content in an unstructured Word document may require hours of professional remediation with Adobe Acrobat Pro to achieve compliance. The architectural decision to use semantic document structure is the highest-leverage accessibility investment any organization can make.</p><p>In Microsoft Word, the accessibility-enabling practices that matter most are: use built-in Heading styles (Heading 1, Heading 2, Heading 3) rather than manually bolding and enlarging text, apply the built-in List Bullet and List Number styles rather than typing dashes or numbers manually, add alt text to every image and chart via right-click → Edit Alt Text, ensure data tables use a proper header row (select the header row → Table Design → check Header Row), and check document accessibility using File → Info → Check for Issues → Check Accessibility before exporting. Word's built-in accessibility checker identifies missing alt text, merged cells in tables, and heading sequence errors. Fixing these in Word takes minutes; fixing them after export to PDF requires professional tools and significantly more time.</p><p>When exporting from Word to PDF for maximum accessibility: use File → Save As → PDF (or File → Export → Create PDF/XPS on Windows) and in the Options dialog, ensure "Document structure tags for accessibility" is checked and "Document properties" is checked. Do not use File → Print → Microsoft Print to PDF — this loses all semantic structure. Do not use third-party PDF printers that lack accessibility features. The File → Save As → PDF method in Word 2016 and later produces tagged PDFs with correct heading levels, paragraph structure, and list markup that transfers from the document's style application.</p><p>For Google Docs: Google Docs exports to PDF via File → Download → PDF Document (.pdf). As of 2024, Google Docs PDF export produces tagged PDFs that include heading structure from the document's paragraph styles. Apply heading styles using the Format → Paragraph styles menu (not manual bold and size) to ensure tags export correctly. Alt text on images is added via right-click → Edit alt text. The exported PDF includes heading tags, paragraph tags, and list tags that support basic screen reader navigation, though complex layouts with sidebars, columns, or floating elements may require post-export verification.</p><p>For organizations that create large volumes of PDFs from templates — application forms, standard agreements, recurring reports — creating an accessible master template and training document creators on the specific style and alt-text practices required for that template is the most scalable approach. A 2-hour training session that teaches the 5 specific Word practices needed to produce accessible exports from a specific form template prevents thousands of accessibility failures per year across the organization's document output.</p><p>For PDFs created from Excel spreadsheets containing data tables: Excel-to-PDF accessibility is limited. Excel's PDF export does not create properly tagged table structures in most cases — headers and data cells are tagged identically, preventing screen readers from establishing column-row relationships. For data tables that must be accessible, the recommended workflow is: create the data in Excel, paste the table into Word (which applies proper header row markup when imported correctly), apply Word table header row formatting, and export from Word to PDF using the accessibility-enabled export settings. This two-step workflow produces accessible tables that Excel-only export cannot achieve. Our tool at <a href="/en/blog/best-pdf-tools-for-small-teams-2026">best PDF tools for small teams</a> covers additional team document workflows for organizations managing high-volume PDF production with accessibility requirements.</p>

1. 1Step 1: In Word, apply Heading 1/2/3 styles to all section titles using the Styles panel. Never create visual headings by manually bolding and enlarging text — manual formatting does not export as heading tags. Run File → Check for Issues → Check Accessibility to identify heading sequence problems before export.
2. 2Step 2: Add alt text to every image, chart, and SmartArt graphic in your Word document. Right-click the object → Edit Alt Text → type a description of the content conveyed by the image. For decorative images, check the 'Mark as decorative' checkbox to exclude them from screen reader output.
3. 3Step 3: Export using File → Save As → PDF (not File → Print → Save as PDF). In the PDF options dialog, confirm 'Document structure tags for accessibility' is checked. This setting is the difference between a tagged accessible PDF and an untagged inaccessible PDF — it defaults to checked in Word 2019+ but should be verified each time.
4. 4Step 4: After export, open the PDF in Adobe Reader and verify: can you highlight and copy text? (If no, it is image-only and requires OCR.) Does the Bookmarks panel show heading navigation? (If not, heading tags may be missing.) Run through PAC 2021 for a complete compliance check before publishing.

<p>Accessibility testing requires both automated tools (which catch structural failures like missing tags, missing alt text, and language declarations) and manual screen reader testing (which evaluates the actual user experience that automated tools cannot fully predict). A comprehensive compliance process uses automated testing first to identify and fix obvious failures, then manual testing to verify that the reading experience is genuinely usable rather than merely technically compliant.</p><p><strong>PAC 2021 (PDF Accessibility Checker) — free, most comprehensive automated check.</strong> PAC 2021 is a free desktop application for Windows developed by the PDF/UA Competence Center at the Swiss organization pdfua.foundation. It checks conformance against PDF/UA-1 (ISO 14289-1) and WCAG 2.1, producing a detailed report identifying every specific failure with the exact tag location in the document. PAC is considered the gold standard for PDF accessibility testing by accessibility practitioners because it checks more compliance points than any other free tool and presents failures in a way that maps directly to remediation actions. Download from pdfua.foundation/pac.</p><p><strong>Adobe Acrobat Reader's built-in accessibility tools (free, limited).</strong> Adobe Acrobat Reader includes a basic accessibility check under Tools → Accessibility → Quick Check, which evaluates whether the document is tagged and whether a language is specified. This check catches the most severe failures but misses many specific WCAG 2.1 requirements. Acrobat Reader Pro ($240/year) includes a full accessibility check that evaluates 32 specific criteria — the same checks available in PAC 2021 for free. For organizations with an existing Acrobat Pro subscription, the integrated checker provides the advantage of working within the same tool used for remediation.</p><p><strong>Screen reader testing — the definitive accessibility validation.</strong> Automated tools check structural conformance but cannot evaluate whether the reading experience is actually understandable and useful for screen reader users. Manual testing with a screen reader — NVDA (free, Windows, nvaccess.org), JAWS (commercial, Windows, most widely used by professionals), or VoiceOver (built into macOS and iOS) — reveals problems like awkward reading order, unhelpful alt text that is technically present but contextually meaningless, form fields that are technically labeled but confusing in sequence, and table data that is technically tagged but announces incomprehensibly in linear audio. For organizations facing ADA compliance requirements, testing with at least one screen reader is considered due diligence that strengthens the defense against discrimination claims.</p><p><strong>Color contrast analyzers (free, browser-based and desktop).</strong> The WebAIM Contrast Checker at webaim.org/resources/contrastchecker requires manual input of color values — useful for checking specific color combinations but not for auditing an entire document. The free Colour Contrast Analyser desktop application (Paciello Group, Windows and macOS) includes an eyedropper tool that samples colors directly from the screen, enabling quick checking of any color combination visible in a PDF viewer without needing to know the hex codes. For documents where color contrast failures are suspected, a 15-minute review with the Colour Contrast Analyser identifies all failures efficiently.</p><p><strong>CommonLook PDF Validator (free online tool).</strong> CommonLook offers a free online PDF accessibility checker at commonlook.com/free-pdf-accessibility-checker that evaluates conformance against Section 508 and WCAG 2.1 specifically — useful for US federal agencies and their contractors who need Section 508 compliance evidence. The online tool processes uploaded PDFs and returns a structured compliance report categorized by Section 508 criterion, which maps directly to the legal standard used in federal procurement and complaint reviews.</p>

1. 1Step 1: Download and install PAC 2021 (free) from pdfua.foundation/pac. Run every PDF through PAC before external publication — the check takes 5–15 seconds per document and identifies every structural compliance failure with the exact tag location for remediation.
2. 2Step 2: For color contrast verification, download the free Colour Contrast Analyser from Paciello Group. Use the eyedropper tool to sample text and background colors directly in your PDF viewer to calculate exact contrast ratios without needing hex code values.
3. 3Step 3: Test critical documents with NVDA (free screen reader for Windows, nvaccess.org). Open the PDF in Adobe Reader with NVDA running, press Insert+F7 to open the Elements List, and verify that headings, links, and form fields appear correctly. Navigate through the document using arrow keys to experience the reading order.
4. 4Step 4: For Section 508 compliance evidence (federal agencies and contractors), use CommonLook's free online checker at commonlook.com to generate a compliance report organized by Section 508 criterion. Save this report as part of your compliance documentation.

<p>PDF/UA (ISO 14289-1, commonly called PDF/UA-1) is the international standard that defines the technical requirements for universally accessible PDF files. Understanding what PDF/UA requires — and how it differs from simply having WCAG-compliant content — is essential for organizations pursuing formal accessibility certification or preparing for accessibility audits that evaluate technical conformance rather than just subjective usability.</p><p>PDF/UA-1, published in 2012 and updated with corrigenda through 2019, specifies requirements at three levels: requirements for PDF files (the structural requirements that a conforming file must meet), requirements for PDF authoring tools (what software that creates PDFs must do to produce conforming output), and requirements for PDF reader software (what viewers must do to present the content accessibly). When organizations evaluate whether their PDFs are accessible, they are evaluating compliance with the PDF file requirements, which PAC 2021 specifically tests.</p><p>Key PDF/UA-1 requirements that go beyond basic tagging: all real content must be tagged (no content can exist in the page content stream without a corresponding tag), no tags may exist without corresponding real content (no empty tags that pad the structure), all tags must use standard PDF structure element types or must be mapped to standard types through the role map, all graphics intended to convey information must have alternative descriptions, the reading order defined by the tag tree must match the logical reading order a human would follow, and all form fields must have a tooltip (which serves as the accessible name). Documents that pass these requirements will function correctly with any PDF viewer that implements PDF/UA rendering support — which includes all major screen readers on current versions of Windows, macOS, iOS, and Android.</p><p>PDF/UA-2 (ISO 14289-2) was published in 2024 and is based on PDF 2.0 rather than PDF 1.7. PDF/UA-2 updates requirements for new PDF 2.0 features including associated files, artifact handling improvements, and Unicode mapping requirements for East Asian scripts. For most organizations working with standard office documents in 2026, PDF/UA-1 compliance remains the applicable standard — PDF/UA-2 compliance is relevant primarily for organizations creating specialized scientific, governmental, or multilingual publications using PDF 2.0-based authoring tools.</p><p>Tagged PDF versus PDF/UA represents an important distinction that is frequently misunderstood in compliance discussions. A tagged PDF has a structure tree, but that structure tree may be incorrect, incomplete, or semantically meaningless — a document tagged entirely with generic Span elements rather than semantically appropriate H1, P, L, and Table elements is technically tagged but not accessible. PDF/UA requires correct semantic tagging, correct reading order, complete alt text on all figures, and all the additional requirements listed above. The presence of the Tags entry in Document Properties confirms a document is tagged; PAC 2021 compliance confirmation is required to assert PDF/UA conformance. For managing accessible documents in collaborative team environments, our guide on <a href="/en/blog/best-pdf-tools-for-remote-work-2026">PDF tools for remote work 2026</a> covers version control and review workflows that can integrate accessibility verification steps before document finalization.</p>

1. 1Step 1: To claim PDF/UA conformance, your document must pass PAC 2021 with zero failures (not just zero errors — both errors and warnings must be addressed). Run PAC and work through the report until all issues are resolved before publishing compliance claims.
2. 2Step 2: Add a PDF/UA conformance marker to your documents using Acrobat Pro (File → Properties → Description → Additional Metadata → XMP). The conformance marker signals to assistive technologies that the document was created to meet PDF/UA requirements, enabling reader software to apply PDF/UA-specific rendering behaviors.
3. 3Step 3: For organizations requiring formal accessibility certification, engage a third-party PDF accessibility auditor to validate conformance of your document templates and production workflow. Self-assessment is sufficient for most compliance situations; third-party certification provides documentation for legal proceedings or regulatory submissions.
4. 4Step 4: Archive the PAC compliance report alongside each published PDF as evidence of due diligence. If an accessibility complaint is filed, documentation showing that the document was tested and found conformant at the time of publication demonstrates a good-faith compliance effort — significantly stronger than having no testing record.