PDF Accessibility Checklist 2026: Complete WCAG 2.2 Compliance Guide

<p>PDF accessibility is no longer optional for organizations that distribute documents publicly. Three regulatory frameworks directly affect PDF accessibility in 2026, and enforcement is increasing across all three.</p><p>The European Accessibility Act (EAA), Directive 2019/882, requires products and services sold in EU member states to be accessible to people with disabilities. Starting June 28, 2025, non-compliant organizations face sanctions including fines and prohibition from operating in EU markets. The EAA covers 'consumer digital services,' which includes PDF documents distributed through websites, apps, and email. The standard referenced is EN 301 549 v3.2.1, which incorporates WCAG 2.1 Level AA. For PDF-specific requirements, this means tagged structure, alt text, and color contrast compliance at minimum.</p><p>In the United States, Section 508 of the Rehabilitation Act mandates that all electronic content created, procured, or distributed by federal agencies must meet WCAG 2.0 Level AA. A 2018 update (the 'Revised 508 Standards') explicitly includes PDFs in this requirement. Government contractors who provide document services or distribute information to federal agencies must ensure their PDFs are 508-compliant — failure can result in contract termination and exclusion from future federal procurement.</p><p>ADA Title III covers places of public accommodation, and courts have consistently extended this interpretation to digital content including PDFs distributed by businesses open to the public. A 2023 ruling in Robles v. Domino's Pizza established a precedent that digital accessibility obligations apply regardless of whether a physical location exists. While PDF-specific cases are fewer than website cases, the legal framework is identical — inaccessible PDFs create the same liability exposure as inaccessible websites for covered entities.</p><p>Beyond legal compliance, accessible PDFs reach more users by design. Screen reader users — estimated at 7.6 million in the United States, according to the National Federation of the Blind — cannot use inaccessible PDFs for their intended purpose. Tagged PDFs also improve usability for keyboard-only navigation, mobile device reflow, and machine reading by search engines and AI systems. A PDF with correct structure tags is more likely to be accurately parsed by AI document systems and search engines — an SEO and discoverability benefit alongside the compliance benefit.</p><p>The business case is measurable. A 2023 Forrester Research study commissioned by Microsoft found that organizations with mature accessibility programs achieved 28% higher customer satisfaction scores and 50% fewer complaints related to document usability. For organizations distributing high volumes of PDFs — annual reports, product documentation, legal agreements, academic publications — a systematic accessibility workflow reduces support burden and expands audience reach simultaneously.</p>

<p>Tagged PDF structure is the single most important accessibility requirement and the most commonly missing element in PDFs distributed in the wild. A 2022 WebAIM analysis of 1 million publicly available PDFs found that 88.6% lacked adequate tagging — making them effectively inaccessible to screen reader users regardless of any other accessibility measures applied.</p><p>PDF tags mirror HTML semantic elements in function. The tag tree includes Heading tags (H1–H6 hierarchy), Paragraph tags (P), Figure tags for images and graphics, Table tags (Table, TR, TH, TD) for structured data, List tags (L, LI, LBody) for bulleted and numbered lists, Link tags for hyperlinks, and Form tags for interactive fields. When these tags are present and accurately reflect the document's structure, screen readers can navigate by heading, jump between form fields, read tables in row order, and skip repetitive navigation elements — the same accessibility patterns that HTML provides in web browsers.</p><p>PDFs created directly from Microsoft Word, Google Docs, and Adobe InDesign with accessibility features enabled automatically include structural tags. PDFs created by scanning a physical document, printing to PDF from a non-accessible application, or exporting from certain legacy tools produce untagged PDFs. These files contain visual content only — the tag tree is either empty or entirely absent. Screen readers reading untagged PDFs either read content in incorrect order (following PDF object creation order, which often differs from reading order) or announce the document as completely inaccessible.</p><p>Remediating an untagged PDF — adding the correct tag structure after the fact — is possible using Adobe Acrobat Pro's 'Make Accessible' wizard or through manual tagging in the Accessibility panel. The automated wizard handles simple single-column documents reasonably well, but complex layouts with multiple columns, sidebars, tables, and figures typically require manual review and correction. A single-column 10-page report takes approximately 1–2 hours to fully remediate manually. A complex 50-page report with multiple layout types can require 8–16 hours of expert remediation work. Creating documents with accessibility in mind from the authoring stage — not as a post-processing step — is consistently more efficient.</p><p>The relationship between PDF accessibility and HTML conversion is directly relevant for web-published documents. If your workflow involves converting PDFs to HTML or HTML to PDF, the conversion quality significantly affects structural tag fidelity. Our guide on <a href='/en/blog/pdf-html-conversion-missing-css-styles'>fixing missing CSS styles in PDF-to-HTML conversion</a> covers how structural tagging interacts with HTML rendering — a common failure point where visual structure appears correct but semantic HTML structure (and by extension PDF tag structure) is lost in conversion.</p>

1. 1Check if your PDF is taggedIn Adobe Acrobat Reader, open File > Properties > Description tab. Look for 'Tagged PDF: Yes' in the Advanced section. Alternatively, open the Accessibility panel and run 'Full Check' — the first item checked is 'Tagged PDF.' If it fails, the document lacks structural tags and requires remediation before it can be considered accessible.
2. 2Set the document languageIn Acrobat Pro, open File > Properties > Advanced tab. Set the 'Language' field to the correct ISO language code (en-US for American English, en-GB for British English, fr-FR for French, etc.). Screen readers use this setting to select the correct text-to-speech voice and pronunciation rules. A PDF without a language declaration defaults to the user's system language, which produces incorrect pronunciation for foreign-language documents.
3. 3Verify heading hierarchy in the tag treeIn Acrobat Pro, open the Tags panel (View > Show/Hide > Navigation Panes > Tags). Expand the tag tree and verify that headings follow a logical H1 → H2 → H3 hierarchy without skipping levels. The document title should be tagged as H1. Major section headings should be H2. Subsection headings should be H3. Decorative headings used for visual styling only should be tagged as Artifact (non-content).
4. 4Check reading order matches visual orderIn Acrobat Pro, use the Reading Order tool (Tools > Accessibility > Reading Order). The numbered order shown in the overlay must match the logical reading sequence — top-to-bottom, left-to-right for English documents. In multi-column layouts, each column must read completely before moving to the next column, not alternating between columns line by line. Reorder content in the Order panel if the sequence is incorrect.

<p>Every image in an accessible PDF requires alternative text — a written description that communicates the image's content and purpose to users who cannot see it. This applies to photographs, diagrams, charts, icons, logos, screenshots, and decorative images. The distinction between informative and decorative images determines whether alt text content is required or whether the element should be marked as an Artifact (excluded from the accessibility tree).</p><p>Informative images — photographs illustrating a product, charts presenting data, diagrams explaining a process, maps showing a location — require alt text that conveys the same information a sighted user receives from viewing the image. For a bar chart showing quarterly revenue by product line, an appropriate alt text is: 'Bar chart showing Q1–Q4 2025 revenue by product. Product A: $12.4M Q1, $14.1M Q2, $11.8M Q3, $16.2M Q4. Product B: $8.3M Q1, $9.1M Q2, $10.4M Q3, $12.7M Q4.' This alt text provides the actual data, not just a description of the chart's visual appearance. Users who cannot see the chart receive equivalent informational value.</p><p>Decorative images — page borders, background textures, dividing lines, watermarks, repeated logos — should be marked as Artifacts in the PDF tag tree, not given empty alt text attributes. An empty alt attribute (alt='') is the HTML approach; in PDFs, marking an element as Artifact achieves the same effect — the screen reader skips the element entirely rather than announcing 'image' or pausing at an unlabeled figure.</p><p>WCAG 2.2 Success Criterion 1.1.1 requires alt text for all non-text content with two key provisions: the alt text must convey the same purpose as the image (not just describe its appearance), and complex images (charts, graphs, diagrams) may require a longer text alternative in addition to brief alt text. For complex images, the pattern is a short alt attribute ('Revenue chart, Q1–Q4 2025 by product') combined with a full data table or extended text description in the document body adjacent to the image.</p><p>PDF alt text is added differently than HTML alt text. In Adobe Acrobat Pro, right-click any Figure-tagged element in the tag tree and select 'Properties' to add or edit alternative text. In Microsoft Word before exporting to PDF, right-click an image and select 'Edit Alt Text' — this alt text carries through to the exported PDF if accessibility features are enabled during export. For Word exports, enabling 'Document structure tags for accessibility' in the PDF export options (File > Export > Create PDF/XPS > Options) preserves all alt text metadata.</p>

<p>WCAG 2.2 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). Large text — defined as 18pt (24px) regular or 14pt (approximately 18.67px) bold — requires a minimum 3:1 ratio. These ratios apply to all text in PDF documents, including body text, headings, captions, form labels, and text within images.</p><p>The most common PDF color contrast failures are: light gray body text on white backgrounds (a ratio of approximately 2.5:1 to 3.5:1 depending on the specific gray), blue hyperlink text on dark blue backgrounds (low contrast between similar hues), and yellow highlighting on white paper (approximately 1.07:1 — nearly invisible to low-vision users and completely invisible to color-blind users who cannot distinguish yellow from white). Corporate branded documents frequently fail contrast requirements because brand colors are chosen for visual identity, not accessibility compliance.</p><p>Checking contrast ratios requires knowing the exact hexadecimal color values of text and background. For PDFs, Adobe Acrobat Pro's accessibility checker reports contrast failures automatically, identifying the element, its color values, and the calculated ratio. Free online tools (WebAIM Contrast Checker, Contrast Ratio by Lea Verou) accept hex color codes and calculate ratios — use these when you know the colors but need to verify the ratio before implementing changes.</p><p>Color alone must never be the only means of conveying information. WCAG 2.2 Success Criterion 1.4.1 prohibits using color alone to distinguish elements — for example, marking required form fields in red without also providing a text label ('Required'), or representing data series in a chart using only color without also using patterns, shapes, or direct labels. This requirement affects PDF design particularly in financial charts, status indicators, and form validation states — all common in documents distributed by regulated industries.</p><p>Practical color contrast targets for PDF templates: use #000000 (pure black) or #333333 (dark gray, ratio 12.6:1 on white) for body text. Use #0066CC (accessible blue, ratio 4.6:1 on white) for hyperlinks. Avoid pure #CCCCCC (light gray, ratio 1.6:1 on white) for any text. For colored backgrounds, use a contrast calculator before finalizing the design — the relationship is non-linear and cannot be reliably estimated visually, particularly for medium-tone colors like teal, olive, and medium gray.</p>

1. 1Run automated contrast checkingIn Adobe Acrobat Pro, go to Tools > Accessibility > Full Check and enable 'Color Contrast' in the checking options. The report identifies specific elements that fail the 4.5:1 ratio requirement, including their location in the document. For PDFs created from Word or InDesign, fix contrast failures in the source file and re-export rather than modifying the PDF directly.
2. 2Check charts and infographics manuallyAutomated accessibility checkers cannot always evaluate text within embedded images or charts. Manually verify that chart labels, axis titles, data labels, and legend text meet contrast requirements against their backgrounds. Use the eyedropper tool in Acrobat, Photoshop, or any color picker to sample the exact hex values, then verify them in a contrast ratio calculator.
3. 3Verify that information conveyed by color has a second encodingReview every use of color in the document as an information signal — red for errors, green for success, blue for links, yellow for warnings. Each must have a secondary encoding: pattern fill, icon, text label, or shape difference that conveys the same information without relying on color perception. This is mandatory for WCAG 2.2 Level AA compliance.

<p>Interactive PDF forms present specific accessibility challenges that go beyond the baseline structural tagging requirements. A form that is visually labeled and logically organized can still be completely inaccessible to screen reader users if the form fields lack proper tooltip text, tab order, and field type declarations. WCAG 2.2 Success Criterion 1.3.5 (Identify Input Purpose) requires that form fields collecting personal information use input purpose identifiers — so a screen reader can announce 'Name field: first name' rather than just 'Text field 1.'</p><p>Each form field in an accessible PDF must have a Tooltip property set to the field's visible label text — for example, a field labeled 'Full legal name' on screen must have Tooltip: 'Full legal name.' Without this, screen readers announce unlabeled fields as 'text field' or 'field number N,' giving users no indication of what to enter. This is the most frequently missed form accessibility requirement: a 2023 SSB BART Group audit of 200 PDF forms from US government agencies found that 73% of forms contained at least one field without a tooltip — making those fields effectively inaccessible.</p><p>Tab order in PDF forms determines the keyboard navigation sequence between fields. WCAG 2.2 requires that focus moves in a logical sequence that matches the visual and functional order of the form. In multi-column form layouts, tab order should move field-by-field across logical groupings, not top-to-bottom-left then top-to-bottom-right. Adobe Acrobat Pro's Forms Editor shows tab order numbers on each field and allows drag-reordering. Verifying tab order is a manual step that automated checkers do not reliably assess.</p><p>Error identification for form validation must also be accessible. When a required field is left empty or a date format is entered incorrectly, the error message must be associated with the specific field through the form field's error description property — not just displayed visually in a color-coded text box nearby. For JavaScript-validated PDF forms, error messages must be programmatically linked to the field they describe.</p><p>For documents distributed as fillable forms through multiple channels — email, website download, internal portals — consider whether a web form (HTML-based) would better serve accessibility needs than a PDF form. HTML forms have significantly more mature accessibility support across assistive technologies. PDFs are most appropriate for forms that must preserve exact visual formatting, require wet or e-signatures, need to be printed and filed physically, or must comply with specific document retention formats like PDF/A.</p>

<p>Accessibility testing for PDFs requires both automated checking and manual verification with assistive technology. Automated tools catch structural issues (missing tags, missing alt text, contrast failures) but cannot verify that the structural choices are semantically correct — for example, that a heading tag actually marks a heading rather than a bold decorative element, or that a table's reading order is logical. Manual testing fills this gap.</p><p>Adobe Acrobat Pro's built-in Accessibility Checker (Tools > Accessibility > Full Check) is the most commonly used automated tool for PDF accessibility. It checks against the PDF/UA-1 specification (ISO 14289-1) and WCAG 2.1 Level AA requirements. The report categorizes failures as 'Failed,' 'Needs manual check,' or 'Passed.' Items marked 'Needs manual check' require human judgment — automated tools cannot determine whether alt text is meaningful or whether reading order is correct without understanding the document's content.</p><p>PAC (PDF Accessibility Checker) 2024 is a free alternative to Acrobat's checker, available from the PDF/UA Foundation. PAC provides more detailed technical reporting on PDF/UA compliance, specifically the logical structure and role mapping of PDF tags. It is particularly useful for identifying tag type errors — where a paragraph is tagged as a heading, or a list item is tagged as a paragraph — that Acrobat's checker may not report clearly.</p><p>Screen reader testing is the gold standard for PDF accessibility verification. NVDA (NonVisual Desktop Access, free for Windows) and JAWS (paid, enterprise standard) are the two most widely used screen readers for PDF testing. The core test: navigate the document using only keyboard commands (Tab to move through interactive elements, arrow keys to read content, H to navigate by heading in NVDA). If this navigation produces a logical, complete experience of the document's content in a meaningful sequence, the document is practically accessible. If it is confusing, incomplete, or reads content out of logical order, remediation is needed regardless of what automated checkers report.</p><p>For organizations using Word as their primary authoring tool, the Word Accessibility Checker (Review > Check Accessibility) catches many issues before PDF export — missing alt text on images, heading hierarchy errors, low contrast text, and unlabeled table headers. Running this check before exporting to PDF is far more efficient than remediating the exported PDF. Similarly, the PDF export settings in Word include an option to include document structure tags for accessibility — this must be explicitly enabled in the export dialog. Our guide on <a href='/en/blog/best-free-pdf-to-word-converter-2026'>the best free PDF-to-Word converters in 2026</a> covers the reverse workflow — converting PDFs back to editable Word format for accessibility remediation when the original source file is unavailable.</p>

1. 1Run Acrobat's Full Accessibility CheckIn Adobe Acrobat Pro, go to Tools > Accessibility > Full Check. Select all checking options and run against the WCAG 2.1 Level AA standard. Review every item marked 'Failed' and every item marked 'Needs Manual Check.' Export the report to a separate PDF and use it as your remediation checklist. Prioritize failures in the order: missing tags > missing alt text > contrast failures > reading order > form fields.
2. 2Test with NVDA in Firefox or ChromeDownload and install NVDA (free at nvaccess.org). Open your PDF in Adobe Acrobat Reader. Press NVDA+F7 to open the Elements List — verify that headings are correctly identified and in logical hierarchy. Press H to jump between headings, verifying sequence and level. Read the first page from top to bottom using the Down arrow key, verifying that reading order matches visual order. This test reveals reading order issues that automated tools miss.
3. 3Verify all images have meaningful alt textIn Acrobat Pro, open the Tags panel and navigate to every Figure element in the tag tree. Right-click each Figure tag and select Properties to view the Alt Text. Verify that each alt text is descriptive — not blank, not 'image,' not the filename. For charts and complex figures, verify that the alt text conveys the data or information the image represents, not just its visual description.
4. 4Check the document title and metadataGo to File > Properties > Description tab. Verify that the Title field contains a descriptive document title — not the filename. Verify that the Language field is set to the correct locale code. Verify that Author, Subject, and Keywords fields are completed for organizational documents — these improve discoverability and are referenced by some accessibility standards for document identification purposes.
5. 5Validate color contrast with actual hex valuesUsing the Color Picker tool in Acrobat or the eyedropper in any color selection tool, sample the exact foreground and background colors for your body text, headings, captions, and form labels. Enter these hex values into WebAIM's Contrast Checker (webaim.org/resources/contrastchecker). Verify all text elements achieve 4.5:1 minimum ratio, all large text (18pt+) achieves 3:1, and all UI components achieve 3:1 for their visual boundaries.