By PDFKits Team — Published February 19, 2026
TL;DR. A PDF is "accessible" when a screen reader can announce its content in the right order, when images have alt text, when headings are tagged as headings (not just bold text), and when interactive forms are operable from a keyboard. The legal floor in the U.S. is Section 508 (federal) and WCAG 2.1 AA (state and private under DOJ guidance updated April 2024); the EU equivalent is EN 301 549 and the European Accessibility Act, taking effect June 2025. The four practical levers — tags, alt text, reading order, forms — cover 90% of compliance. Testing requires both an automated checker (PAC 2024, Adobe's built-in checker) and a real screen reader run (VoiceOver on macOS, NVDA on Windows).
Three frameworks govern PDF accessibility in practice. WCAG 2.1 AA is the technical standard nearly all governmental and many private organizations are bound to, either directly (federal sites) or through state-level laws (California's Unruh Act, New York's Human Rights Law) and DOJ guidance under Title II and Title III of the ADA. Section 508 applies to U.S. federal agencies and their contractors and largely incorporates WCAG 2.1 AA by reference under the 2018 refresh. EN 301 549 is the EU standard for public-sector accessibility under Directive 2016/2102, and the Accessibility Act (EU 2019/882, effective June 28, 2025) extends similar requirements to private-sector products including digital documents.
For PDFs specifically, all three regimes point to the same technical baseline: PDF/UA (ISO 14289-1) compliance, which operationalizes WCAG for the PDF format. Achieving PDF/UA means the document has proper tag structure, alternate text on all images, defined reading order, language declarations, and either content-stream-level redaction (not annotations) or a tagged structure that screen readers can announce correctly.
A tagged PDF has an internal tree of structural elements: H1, H2, P, Figure, List, Table, etc. — analogous to HTML semantic markup. Screen readers traverse this tree to announce content meaningfully. An untagged PDF looks the same visually but reads as a flat stream of words to a screen reader, with no way to skip headings, jump between sections, or understand table structure. The first question of any accessibility audit is "is this PDF tagged?" If the answer is no, nothing else fixes it.
Every meaningful image needs an alt text describing its content for users who cannot see it. A bar chart needs alt text that summarizes the data ("Q4 revenue grew 12% over Q3, with North America contributing 60% of growth"), not just "bar chart." Decorative images that add no information (a wavy line separating sections) should be marked as artifacts so screen readers skip them rather than reading something useless aloud. The most common failure: company logos read as "logo of XYZ Corp" on every page header, becoming repetitive noise for users with screen readers.
Visual layout — two columns, a sidebar, a callout box — does not match content order from a screen reader's perspective. A tagged PDF defines the logical reading order separately from the visual layout. A two-column page should read left column top-to-bottom, then right column, not zig-zagging across columns. Footnote callouts should read in the footnote, not interrupt the body text. Reading order errors are the most common accessibility bug because they look fine on screen but break the document for non-visual users.
Form fields need text labels associated programmatically (not just placed visually nearby), keyboard tab order matching visual order, and an indication of required vs optional. A form field labeled only by a "*" next to it is invisible to a screen reader. A form whose tab order jumps around the page is unusable without a mouse. Both issues come up constantly in PDF forms exported from Word or InDesign without explicit accessibility setup.
A consulting firm bidding on a federal contract submits a 200-page proposal. The RFP requires Section 508 compliance for all deliverables. The firm's proposal, exported from Word, has untagged headings (visually H2, structurally just bold body text) and unlabeled images. The submission fails the procurement's accessibility checklist. Retagging the document in Acrobat Pro takes a day; the underlying lesson is to export with accessibility checking from the source.
A state university distributes scanned reading packets to students with visual disabilities. The unprocessed scans are image-only PDFs — impenetrable to screen readers. The OCR layer (added via PDFKits OCR PDF) makes text extractable, but for full accessibility the document still needs tagging and reading order definition. The two-step workflow — OCR first, then tag — is standard for legacy scanned material.
A company sends offer letters as PDFs to candidates, including candidates with screen reader needs disclosed during interview accommodations. An untagged offer letter requires the candidate to ask for an accessible version — friction that signals the company doesn't take accessibility seriously. Tagging the template once means every future letter is accessible by default.
An ADA Title III plaintiff is challenging a business's inaccessible website. The complaint itself, filed as a PDF, must be accessible — both because it is a court document and because the plaintiff's audience includes the court's ADA coordinator. An accessible filing demonstrates the plaintiff's good faith.
An insurance company distributes annual benefit summaries to plan members. Federal Affordable Care Act regulations require accessible formats for members with disabilities. An accessible PDF satisfies this for visually impaired members; the alternative is producing separate large-print and audio versions, which is more expensive and harder to maintain.
Start from a source document that supports accessibility. Word documents with proper heading styles, alt text on images, and table structure produce tagged PDFs on export via File → Save As → PDF → Options → "Document structure tags for accessibility." Google Docs has equivalent export. InDesign requires explicit accessibility setup but produces well-tagged output when configured. PDFKits can flatten and clean existing PDFs but cannot fully re-tag an untagged document — re-export from the source where possible.
Add alt text in the source. In Word: right-click an image → Edit Alt Text. In InDesign: Object → Object Export Options → Alt Text. In Google Docs: right-click → Alt text. Write descriptions for content images; mark decorative images as decorative. Avoid "image of," "photo of" — screen readers already announce these as images.
Verify reading order on export. Open the resulting PDF in Acrobat (or any PDF viewer with reading-order display). Reflow the document (View → Page Display → Reflow). The reflowed content should match the intended reading order. If it doesn't, the source document's layout needs work — pull quotes, sidebars, multi-column layouts often confuse the tagger.
Run an automated check. PAC 2024 (free, Windows) is the standard PDF/UA validator. Adobe Acrobat Pro's built-in Accessibility Checker is faster but less strict. Both flag specific issues with page numbers and recommendations.
Run a real screen reader test. Open the PDF in a screen reader: VoiceOver on macOS (Cmd+F5), NVDA on Windows (free). Navigate by headings (H key in NVDA, VO+Cmd+H in VoiceOver). Listen for: structural navigation that works, alt text that makes sense, reading order that flows naturally, and form fields that announce their labels.
| Capability | PDFKits | Adobe Acrobat Pro | PAC 2024 | Word/InDesign export |
|---|---|---|---|---|
| Cost | Free | $29.99/month | Free | Office subscription |
| Add OCR layer to scanned PDFs | Yes | Yes | No (read-only check) | No |
| Edit existing tag tree | No | Yes (granular) | No | Source only |
| Add/edit alt text | No (use source) | Yes | No | Yes |
| Reorder pages and edit structure | Yes (page-level) | Yes (page + tag) | No | Source only |
| Files stay on your device | Yes | Yes (desktop) | Yes | Yes |
| Automated PDF/UA validation | No | Limited | Yes (gold standard) | No |
PDFKits is the right tool for the surrounding workflow — OCR'ing scans before tagging, splitting and merging accessible files, sanitizing metadata, cropping pages — but the tag-tree editing itself is a job for Acrobat Pro or for re-export from a properly-prepared source. The realistic accessibility stack is: source document → properly-exported tagged PDF → PAC 2024 for validation → NVDA/VoiceOver for a human-in-the-loop test. PDFKits fits in the preparation and post-export sanitization steps.
Believing the visual check is enough. A document that looks fine visually can be completely broken for screen readers. Tagging defects are invisible without an inspector. Always validate.
Decorative images announced as content. A wavy line between sections marked as a regular image gets announced ("image") repeatedly, becoming noise. Mark such images as artifacts so screen readers skip them.
Tables built with tabs and spaces. A "table" that is actually fixed-width text arranged with spaces collapses for screen readers. Real tables (Word table objects, InDesign table objects) survive export with structure; ASCII tables do not.
Color-only signaling. "Red items are urgent, green items are complete" fails for users who cannot see color. Pair color with text labels or icons. WCAG 2.1 explicitly requires this under Success Criterion 1.4.1.
Form fields without programmatic labels. A label placed visually next to a field but not associated with it via tagging is invisible to screen readers. In Acrobat: select field → Properties → Tooltip. In Word forms: right-click → Properties → Title.
Skipped heading levels. H1 → H3 (skipping H2) confuses screen reader navigation. Maintain a logical heading hierarchy: H1 for document title, H2 for sections, H3 for subsections.
No. Selectable text is necessary but not sufficient. A screen reader can read selectable text, but without tags, it cannot navigate by heading, skip decorative content, or announce table structure correctly. Tagging is the qualitative difference.
Not at present. Tag-tree editing requires Adobe Acrobat Pro or the re-export-from-source workflow. PDFKits handles OCR (necessary first step for scanned PDFs), page-level operations, and sanitization, but not granular tag editing.
PDF/A is the archival standard — ensures long-term preservation by embedding fonts and prohibiting external dependencies. PDF/UA is the accessibility standard — ensures screen reader compatibility. A document can be both simultaneously (PDF/A-2u + PDF/UA), which is the gold standard for government archives.
OCR is necessary but not sufficient. After OCR, text is extractable, but the document still needs tags, reading order, alt text on any figures, and language declarations. OCR is step one of perhaps four.
Test with at least two: NVDA on Windows (free, the de facto industry standard for testing) and VoiceOver on macOS (built into the OS, used by many real users). If you only test on one, NVDA covers the widest real-user base.
DOJ guidance issued April 2024 clarified that Title III of the ADA reaches business websites and digital documents, with WCAG 2.1 AA as the de facto benchmark. The new Title II rule (effective for state and local governments April 2024/2026 depending on entity size) explicitly references WCAG 2.1 AA. Private businesses face exposure under Title III if their documents are inaccessible to users with disabilities.
Modestly — a tagged PDF is typically 5–15% larger than its untagged equivalent. The tag tree adds bytes but rarely doubles file size.
Signing does not break the tag tree. However, some signature workflows flatten the document, which can lose interactivity. For accessible signed PDFs, use a signing tool that preserves the underlying structure.
Yes, but it is a two-step rebuild. OCR the scan to extract text, then either (a) re-create the form as a tagged PDF in Acrobat Pro, or (b) reproduce the form in HTML — often easier than fighting a scanned PDF into compliance.
Describe the chart's purpose and the key takeaway, not the visual mechanics. "Bar chart showing quarterly revenue" is weak. "Q4 revenue exceeded Q3 by 12%, driven by 60% growth in North America" is meaningful for a non-visual reader. For data-heavy charts, also provide a data table in the document body.
OCR PDF — Add a text layer to scanned PDFs before tagging. Edit PDF — Adjust visible content; combine with Acrobat for tag editing. Clean Metadata — Strip author info before publishing. Rearrange Pages — Fix reading order at page level. Extract Pages — Isolate sections for targeted accessibility fixes. Split PDF — Break a large document into per-chapter accessible files.