Tagged PDF or hosted HTML? The two paths that make a document accessible

The two paths in one sentence

Path A. Tagged PDF. The original PDF with a proper accessibility tree underneath: structured headings, reading order, alt text, language, table structure, and metadata. Same file, same layout, now readable by assistive technology.
Path B. Hosted HTML (content alternative). A parallel, equally accessible web page that renders the same content as responsive, semantic HTML. Lives at a stable URL you control. Editable in the browser. Indexable by search engines. Designed to be the primary reading experience when the content is public-facing.

Why the hosted HTML version is often the better experience

Standards let you meet WCAG and ADA Title II with a tagged PDF on its own. You don’t have to publish an HTML version. But the reason the WCAG conforming alternate version concept exists, and the reason most accessibility-focused government and education teams ship the HTML alongside the PDF, is simple: for readers on the web, the HTML experience is better on almost every axis.

Speed. An HTML page renders in milliseconds. A PDF of the same content commonly downloads at 1 to 10 MB and takes seconds to open, longer on mobile connections.
Mobile reading. HTML reflows. A two-column, paginated PDF on a phone forces pinch-to-zoom and horizontal scrolling, which is exhausting and often leaves assistive tech users stuck.
Assistive technology. Screen readers navigate native HTML semantics (headings, lists, tables, landmarks) more reliably than any PDF tag tree. Users can jump by heading, skip to main, and move through tables by cell without the quirks PDF tags can introduce.
Search and discovery. Google and Bing index hosted HTML pages richly. PDFs are indexed but rank lower and surface less useful snippets. If you want people to find the document, HTML wins.
Linkability and sharing. A URL can be shared in email, Slack, and social posts and renders a preview. A PDF link just opens a download.
Maintenance. Fix a typo in the browser and the change is live. Update a PDF and you ship a new file, bust caches, and often leave stale copies in the wild.
Accessibility headroom. HTML can carry dark mode, adjustable line spacing, reading rulers, and translation. PDFs cannot.
Compliance flexibility. When the source PDF is scanned, scraped, or otherwise poorly structured, the HTML alternative is often the cleanest honest path to WCAG 2.2 AA. Rather than wrestling a broken tag tree, you publish a web page that is correct by construction.

Path A. Tagged PDF, in detail

A tagged PDF is the same visual document with a machine-readable structure tree underneath. Assistive technology reads the tree; sighted users see the unchanged layout. This is the ISO 14289 (PDF/UA-1) conformance path. Under ADA Title II and Section 508, a properly tagged PDF is an accessible deliverable on its own.

Ship the tagged PDF when

The document is a form, contract, policy, or signed record.
Users will download it, archive it, or read it offline.
Pagination, layout fidelity, or print output matters.
The PDF is the legal or archival record of truth.
You’re migrating a legacy PDF library and the team that owns it wants PDFs, not web pages.

What you get from DocAccessible

Tag tree with headings, lists, tables, figures, and reading order.
Alt text on every image, AI-generated, editable before export.
Document title, primary language, and Marked=true metadata.
Table header rows and scope attributes where layout allows.
A WCAG 2.2 AA score and prioritized issue list, so you can see what changed and what still needs a human eye.

Path B. Hosted HTML content alternative, in detail

The hosted HTML alternative renders your document as a web page at a URL you control (for example docaccessible.com/d/your-slug). It is not a screenshot, not a PDF embed, not an iframe. It is semantic HTML with real headings, lists, tables, images, and landmarks, editable in the browser and responsive on every device.

This is the Section 508 “equivalent facilitation” and WCAG “conforming alternate version” concept shipped as a product. Historically this path existed as a compliance fallback for when a PDF could not be remediated. In practice, for anything that lives on the public web, it is the better reading experience and deserves to be the version you promote.

Publish the hosted HTML when

The document is public-facing information: policies, reports, announcements, annual filings, benefits guides, research papers, course materials.
You want the content to be findable in search.
Readers will view it on phones, tablets, or with screen readers.
The content will change and you want to edit in place, not re-upload PDFs.
The source PDF is scanned, scraped, or too poorly structured to tag cleanly.
You want a canonical link you can share, embed, or send in email.
You care about dark mode, responsive typography, or translation support.

What the hosted page includes

Semantic HTML5: real <h1>, <nav>, <main>, <table> with headers, lists, landmarks.
WCAG 2.2 AA contrast, focus states, skip links, keyboard navigation.
Alt text on every image, editable inline.
Version history, so earlier revisions are recoverable.
Visibility controls: private, unlisted, or public, with optional password.
Open Graph and structured data for rich sharing and search.
A permanent URL that survives edits.

Shipping both: the best of each path

Many teams publish both and cross-link them. The tagged PDF is the archival record; the hosted HTML is where readers land.

Government policies. The PDF is the official version for legal and records retention. The HTML is what shows up on search and what most readers use.
Annual reports. Investors and auditors want the PDF. Everyone else reads the HTML.
Long-form guides. A downloadable PDF for offline reading, an HTML page for quick reference and search.
Course materials. PDF for printing or archiving, HTML for students reading on phones.

In DocAccessible this is a per-document decision: publish the PDF, publish the hosted HTML, or publish both. Upload once; ship whichever the document needs.

A quick decision framework

Who reads this on the web?If the answer is “the public, constituents, students, customers, or anyone searching for it,” publish the hosted HTML version. It is measurably the better reading experience.
Does the PDF have to stay a PDF? Forms, contracts, signed records, legal filings, certificates: yes, keep the tagged PDF as the deliverable.
How bad is the source PDF? Scanned image, scraped text, broken columns: the hosted HTML is usually the faster path to clean compliance than rescuing the tag tree.
Will this content change? If yes, the hosted HTML wins on maintenance. Edit in place, done.
Do you need both? For most public-sector and education content, yes. Ship the PDF as the official artifact and the HTML as the reading experience.

What DocAccessible does for every upload

Tagged PDF with a PDF/UA-aligned tag tree, alt text, language, and metadata.
Hosted HTML page at a URL you control, with full WCAG 2.2 AA treatment: semantic markup, landmarks, keyboard navigation, contrast, focus.
A WCAG 2.2 AA score and a prioritized issue list so you know exactly what changed and what still needs attention.
A live editor for the hosted page. Fix a heading, rewrite alt text, correct a table header, save, done.
Visibility controls so you decide who sees the hosted version: private, unlisted, public, or password-protected.

The short version

A tagged PDF is an accessible PDF. A hosted HTML page is an accessible web page of the same content. Both are compliant. For anything the public reads on the web, publish the HTML version. For anything that has to stay a PDF, ship the tagged PDF. For the common middle ground, ship both and let each serve its audience.