Accessible PDF from HTML: what tagged output gives you, and where it stops

Accessibility used to arrive late in an HTML to PDF project, usually as a line in a procurement questionnaire nobody had read. That changed when the Department of Justice published its ADA Title II rule in 2024, adopting WCAG 2.1 Level AA for state and local government web content and documents, with compliance dates that have now started to land. If you sell to government, to education, or to anyone who does, the question of whether your generated PDFs are accessible is being asked in writing.

This guide covers what a tagged PDF actually is, what headless Chromium does and does not produce, and how to get the best output the pipeline can give you. It also says plainly where automated HTML to PDF conversion stops being enough, because pretending otherwise would cost you an audit.

The short version

Headless Chromium can emit a tagged PDF, and Puppeteer, Playwright and any tool built on the DevTools Protocol expose it through the generateTaggedPDF option on Page.printToPDF. Tagging carries your HTML semantics into the PDF as a structure tree, so headings, lists, tables and alt text survive for screen readers. What it does not do is produce a file that conforms to PDF/UA, the ISO 14289-1 standard: Chromium's own documentation has stated it does not generate PDF/UA compliant files. So the practical position is that good semantic HTML plus tagged output gets you a genuinely usable document and most of WCAG, while formal PDF/UA conformance still needs validation and, often, remediation in a dedicated tool.

What the rules actually require

Two regimes matter for US buyers, and they are frequently confused.

Regime	Who it binds	Standard referenced	Timing
Section 508	Federal agencies, their contractors, and recipients of federal funding	Revised 508 standards incorporate WCAG 2.0 Level A and AA for electronic documents; agencies commonly work to 2.1 AA in practice	In force since the revised standards took effect in 2018
ADA Title II	State and local government entities, and often their vendors by contract	WCAG 2.1 Level AA, per the DOJ 2024 final rule	Staggered by entity size, with the first compliance date on April 24, 2026 for larger public entities and April 26, 2027 for smaller ones

The practical consequence for a software vendor is indirect but real. You may not be a covered entity, but if your product generates PDFs that a covered entity sends to the public, their obligation becomes your requirement, and it arrives as a procurement question or a contract clause. Meeting WCAG 2.1 AA for your generated documents satisfies both regimes in most cases, and building to WCAG 2.2 AA covers you further ahead.

What a tagged PDF is

An untagged PDF is a set of instructions for drawing marks on a page. It knows a string of glyphs is at certain coordinates in a certain font. It has no idea that string is a heading, or that another block is a table cell, or in what order a human should read any of it. A screen reader given an untagged PDF has to guess, and it usually guesses by position, which is why untagged multi-column documents get read across the columns as nonsense.

Tagging adds a parallel structure tree describing what each piece of content is and in what order it should be consumed. The tags that carry the most weight in practice:

In your HTML	Becomes in the PDF	What it does for a user
h1 to h6, in order	H1 to H6 structure elements	Lets a screen reader user jump between sections instead of reading linearly
ul, ol, li	L, LI, LBody	Announces list membership and position, "item 3 of 7"
table with th and scope	Table, TR, TH, TD with header associations	Reads the relevant column and row header with each cell, which is the difference between a usable and an unusable data table
img with alt	Figure with alternate text	Describes the image; an empty alt marks it decorative and skippable
lang on the html element	Document language	Selects the right pronunciation engine
DOM order	Reading order in the structure tree	Determines the sequence content is announced in

The important thing to take from that table is where the quality comes from. The converter does not invent structure. It translates the structure you gave it. A PDF generated from markup built out of styled div elements will be tagged, and still be useless, because there was nothing to carry across.

Turning it on

In raw CDP terms it is one parameter on the print call:

const pdf = await page.pdf({
  format: 'Letter',
  printBackground: true,
  tagged: true,          // maps to generateTaggedPDF
  outline: false
});

Two warnings worth more than the code. First, the old command line flag path and the DevTools Protocol path are not equivalent, and the CLI --print-to-pdf mode has historically not supported the full option set that the protocol does, so verify your tool is going through the protocol rather than shelling out to a binary. Second, and this one silently destroys the work: if you post-process the PDF through Ghostscript, for compression or PDF/A conversion, standard invocations strip the structure tags out again. Teams add a compression step months later and quietly break accessibility for everything downstream. If you must post-process, validate the output afterward rather than assuming.

Getting the input right

Since tagging only carries across what exists, the work is in the HTML. For a document template, in rough order of payoff:

1. Use real headings in a sensible order. One h1, then h2 for sections, and do not skip levels for visual reasons. Style them however you like; the level is semantic, not a size.
2. Mark up data tables properly. th for header cells with an explicit scope of row or col, a caption describing the table, and thead so headers repeat when the table crosses pages. Never use a table for layout.
3. Write real alt text, and mark decorative images as decorative. A logo that appears next to the company name in text does not need describing, so give it alt="". A chart does: describe what it shows, not that it is a chart.
4. Set the language. One attribute, lang="en-US", and mark any passage in another language inline.
5. Check reading order in the DOM, not on screen. CSS grid and flexbox can reorder content visually while the DOM order stays as written, and it is the DOM order that becomes the reading order.
6. Meet the contrast requirement in print colors. WCAG 2.1 AA wants 4.5 to 1 for normal text. Light grey captions that pass on a bright screen often fail on paper, and print stylesheets that convert to greyscale change the ratios entirely.
7. Give the document a title. The PDF title property should be a human description, not invoice_final_v3.html.

Most of this is ordinary good HTML, which is the pleasant part: the same discipline that makes your web pages accessible makes your PDFs accessible, and you do it once. Whether it actually happens usually depends less on tooling than on whether the people writing these templates know the rules at all, which is a training and onboarding problem more than an engineering one.

Where automated conversion stops

Being straight about the ceiling. A tagged PDF from good HTML gets you a document that works well with assistive technology and satisfies a large share of WCAG 2.1 AA. It does not automatically get you a certificate of PDF/UA conformance, and if a contract names ISO 14289-1 explicitly, you need to verify rather than assume.

The gap tends to sit in details the converter cannot decide for you: whether an image is genuinely decorative, whether a complex table needs additional header association, whether the metadata declares conformance, and whether artifacts such as running headers are correctly marked as artifacts rather than content. Validate with a PDF/UA checker such as the open-source veraPDF, and expect that documents in a regulated procurement will go through a remediation tool at least once before sign-off.

The honest recommendation: generate the best tagged output you can from clean semantic HTML, validate it, and budget for remediation on the specific document types that face a formal conformance requirement. Trying to hit PDF/UA purely by tweaking your HTML converter is a long road, and a specialist tool covers the last stretch faster.

Frequently asked questions

Can headless Chrome generate an accessible PDF?

Yes, up to a point. Chromium supports tagged PDF output through the generateTaggedPDF option on the print call, which carries HTML semantics such as headings, lists, tables and alt text into the PDF structure tree so screen readers can use them. It does not produce files that formally conform to the PDF/UA standard, so conformance still requires validation and often remediation.

What is the difference between a tagged PDF and a PDF/UA compliant PDF?

Tagging is a technique: adding a structure tree that describes what content is and its reading order. PDF/UA, ISO 14289-1, is a formal standard specifying how that structure must be built and declared, covering metadata, artifacts, header associations and more. Every PDF/UA file is tagged, but a tagged file is not automatically PDF/UA compliant.

Does converting HTML to PDF preserve alt text?

It does when tagged output is enabled. The alt attribute on an image becomes alternate text on the corresponding Figure element in the PDF structure tree, and an empty alt marks the image as decorative so assistive technology skips it. With tagging off, alt text is discarded entirely because an untagged PDF has nowhere to store it.

Do generated PDFs need to meet Section 508?

If they are produced or used by a federal agency, a federal contractor, or an organization receiving federal funding, yes, documents fall within scope. Vendors who are not directly covered still meet the requirement in practice through contract terms, since a covered customer cannot distribute an inaccessible PDF your product generated on their behalf.

Why did my PDF lose its accessibility tags?

The most common cause is post-processing. Running a tagged PDF through Ghostscript for compression or format conversion strips the structure tags with standard invocations, which disables assistive technology support even though the visible document is unchanged. Check any step in your pipeline that rewrites the file, and validate the final artifact rather than the one your renderer produced.

Where we stand

Sitepdf renders with managed Chromium, so tagged output is the same capability described above, with the same honest ceiling: good semantic HTML in gives a properly tagged document out, and we are not going to claim PDF/UA certification we do not have. If your requirement names ISO 14289-1 in a contract, validate with veraPDF and plan a remediation step for those document types.

For the practical side of getting the input right, our guides on page breaks and repeating table headers and why CSS gets dropped in conversion cover the markup issues that most often degrade both appearance and structure. The PDF generator API page lists the render parameters, and you can try the converter at the top of this page on any URL to see what your own templates produce.