Accessible PDF Generation from HTML: Tagged PDF, ADA Compliant PDF and Section 508 Output

An accessible PDF is one that assistive technology can interpret rather than guess at. Six things carry almost all of the weight, and five of them are decided in your HTML before any rendering happens.

• A tag structure. Headings, paragraphs, lists, tables and figures marked as what they are, in a parallel tree alongside the visual content.
• A logical reading order. The sequence a screen reader announces content in. Untagged multi column layouts get read straight across the columns, which is why they come out as nonsense.
• Alternative text on meaningful images, and images that are purely decorative marked as artifacts so they are skipped rather than announced.
• Real table headers. A th with a scope becomes a header association in the PDF, so each cell is read with its column and row header attached. This is the single difference between a usable and an unusable data table.
• A document language, so the right pronunciation engine is selected, plus a document title.
• Text that is actually text. Selectable, searchable vector text rather than an image of a page.

Notice what is not on that list: how the document looks. Accessibility is about the structure underneath the appearance, which is exactly why generating from HTML has a structural advantage over scanning or over drawing a layout by hand. You already have a semantic document. The job is to not lose it on the way into the PDF.

An untagged PDF is a set of drawing instructions. It knows that a run of glyphs sits at certain coordinates in a certain font. It has no idea that the run is a level two heading, that another block is a table cell, or in what order a human should consume any of it. Tagging adds a structure tree describing exactly that.

When you render from HTML, the mapping is direct, and it is worth knowing because it tells you where quality comes from:

• h1 to h6 become H1 to H6 structure elements, which is what lets a screen reader user jump between sections instead of listening linearly.
• ul, ol and li become L, LI and LBody, so list membership and position are announced.
• A table with th and scope becomes Table, TR, TH and TD with header associations.
• An img with alt becomes a Figure with alternate text.
• lang on the html element becomes the document language.
• DOM order becomes reading order.

The consequence is blunt. The renderer does not invent structure, it translates the structure you gave it. A document built out of styled div elements with visual sizing instead of headings will be tagged, and will still be useless, because there was nothing meaningful to carry across. Teams that treat accessibility as a rendering setting rather than a markup discipline discover this at audit, not before.

Two regimes drive nearly every accessibility clause a US software vendor sees, and they are routinely confused with each other.

Section 508 binds federal agencies, and reaches contractors and recipients of federal funds through procurement. The revised standards incorporate WCAG Level A and AA for electronic content, and it has been in force for years. If you sell to a federal agency, accessibility is a line item in the solicitation and often a VPAT request.

ADA Title II is the newer pressure. The Department of Justice published its web and mobile app rule in the Federal Register on 24 April 2024, adopting WCAG 2.1 Level AA for state and local government web content, and conventional electronic documents including PDFs are explicitly in scope.

The dates moved, and most published guidance has not caught up. On 20 April 2026 the Federal Register published an Interim Final Rule extending the compliance deadlines. The current dates are 26 April 2027 for public entities with a total population of 50,000 or more, and 26 April 2028 for entities under 50,000 and for special district governments. Plenty of articles written in 2024 and 2025 still print April 2026 as the first deadline. It is worth checking the current date before you plan a remediation budget around it, in either direction.

There is also an exception worth knowing: conventional electronic documents posted before a covered entity compliance date are generally exempt, unless they are currently being used to apply for, access or participate in a service. Documents created after the date are not exempt, which is precisely why generated documents matter. A statement, invoice, permit or report that your system produces every month is being created new every time.

If you are a software vendor rather than a covered entity, the obligation still lands on you indirectly. Your customer is covered, your product generates the PDFs they send to the public, and their duty becomes your contract clause. That is why this arrives as a procurement questionnaire rather than a lawsuit, and the document it asks for by name is almost always an Accessibility Conformance Report. Our page on the VPAT and Accessibility Conformance Report covers which edition to complete, what each conformance rating commits you to, and the Level A rows that untagged output makes impossible to claim honestly.

The work is mostly upstream. In rough order of how much difference each step makes:

1. Fix the source markup first. Real heading levels in order with no skips, real lists, real tables with th and scope, alt on every meaningful image and alt="" on decorative ones, and lang on the html element. No step further down this list can compensate for skipping this one.
2. Set the reading order by DOM order. CSS that visually reorders content, particularly flexbox order and grid placement, does not reorder the tag tree. What looks like a sensible two column layout can be announced in an order nobody intended. Lay the document out in the order it should be read.
3. Turn tagging on at render time. With Chromium it is one parameter. It is off by default in many wrappers, which is the most common reason a team believes they are producing tagged output and is not.
4. Give the document a title and language in metadata, not only in the visible header.
5. Check what came out. Not what you intended, what the file contains. Free tools do this in seconds.
6. Do not run the file through a tool that strips the tags. This is the failure nobody expects: merge, compress, watermark, flatten and some signing steps can silently discard the structure tree. Validate after the last step in the pipeline, not after the render.

Our guide on accessible PDF from HTML walks through the tagging behaviour in more detail, and how to test PDF accessibility covers the checkers, what they catch and what they cannot.

Every vendor in this category has an incentive to imply that switching on a flag makes a document compliant. It does not, and pretending otherwise is how a team fails an audit it thought it had passed.

Tagged is not conformant. PDF/UA-1 is a formal ISO standard with specific requirements, and emitting tags is a necessary but not sufficient step toward it. Chromium has no PDF/UA mode at all. WeasyPrint, which does have PDF/UA variants, states plainly that generated documents are not guaranteed to be valid and that checking is the responsibility of the user. That is the honest position for the whole category.

Some requirements are not machine decidable. No renderer can tell whether your alternative text is a useful description or the string "image1.png". None can judge whether a heading level reflects the actual document hierarchy, whether colour alone is carrying meaning, or whether reading order makes sense to a human. The PDF Association Matterhorn Protocol organises PDF/UA conformance into 31 checkpoints and 136 failure conditions, and while most can be identified by software, a substantial set requires human judgment. That is a structural property of accessibility, not a gap in any product.

Complex content stays hard. Multi level nested tables, data visualisations, mathematical notation and interactive forms all need deliberate work beyond good markup. A chart rendered as an image needs a real text description of what it shows, not a label.

The realistic position for a team generating documents at volume: good semantic HTML plus tagged output gets you a genuinely usable document and most of the way to WCAG, and it scales to a million files at no extra cost per file. Formal PDF/UA conformance on a document that a regulator will scrutinise still deserves validation and, sometimes, remediation in a dedicated tool. Anyone who tells you their renderer removes that step is selling you a future audit finding. If you are choosing what to validate with, our PDF accessibility checker comparison prices six tools and shows which of them actually decide PDF/UA conformance rather than just listing issues.