PDF accessibility vs HTML: when to keep a document and when to move it online

Let's discuss your project →

If a document is part of the service you deliver, the first question is not whether you can export it as a PDF. The first question is what the user needs to do with it.

When the content must be read, searched, updated, or followed step by step online, HTML is usually the better default. PDF still has a role, but it works best as a second format: printable, archivable, or downloadable. For service content, the authoritative version should normally be the one that is easiest to use on the web.

That choice is not just editorial. The WCAG overview and WCAG 2.2 are the W3C reference framework for web accessibility, and Directive (EU) 2019/882 sets accessibility requirements for products and services within its scope. In practice, the format you choose can affect usability, governance, and the quality of the service experience.

HTML first, PDF only when it has a clear job

Use HTML as the primary format when the content is:

part of a public service or workflow;
expected to be found through search;
likely to change over time;
long enough to need headings, navigation, and links;
something users must act on, not just read.

Use PDF as a supporting format when you need:

a fixed layout for print or archiving;
a stable snapshot version;
a downloadable copy that mirrors an official document;
a secondary version that does not replace the web page.

That is the practical rule. If the content is instruction-heavy, the web page should be the authoritative version. If PDF is the only version, you are asking every user to work inside a layout that may be harder to navigate, search, or understand with assistive technology.

What usually breaks in PDF-first publishing

Teams often choose PDF because it seems simple: one file, one export, one download link. The cost appears later, when the same content must be read by keyboard users, screen reader users, or people who need to scan quickly on mobile.

The most common failure modes are predictable:

headings are visual, but not structured as headings;
the reading order does not match the visual order;
tables are used for layout instead of data;
links say “click here” instead of describing the destination;
important text is embedded in images;
the PDF and HTML version diverge after an update;
forms or instructions are present, but not easy to follow without the original layout.

None of those problems is solved by making the PDF look more polished. They are solved by changing how the information is structured.

A simple decision table before publication

Question	If the answer is yes	Safer default
Is the document part of an online service flow?	Users must act on it, not just read it	HTML first
Does the content change often?	Version drift is a real risk	HTML primary, PDF derived
Do users need to search, skip, or revisit sections?	Navigation matters	HTML primary
Do you need a printable or archive version?	A second format is useful	PDF as support
Does the document contain operational steps or rules?	The structure must be explicit	HTML, with PDF only if needed

This is not a legal test. It is a working rule for editorial and product teams that need to decide what to build first.

Simulated case: one guide, two formats

Simulated example. A company publishes a 12-page customer guide explaining how to request support, attach documents, and track a case. The communication team wants to keep the PDF because “it prints nicely.” The product team notices that the same guide is also used by people who navigate only with a keyboard or who need a screen reader.

Before

one downloadable PDF only;
a cover page with decorative elements;
a table of contents that is not interactive;
section titles that exist visually but not semantically;
links written as generic calls to action;
important notes placed inside sidebars and boxes;
no equivalent HTML page.

The content exists, but the user experience depends on seeing the page exactly as designed.

After

an HTML page with a clear title and sections;
a logical heading structure;
ordered steps for the request flow;
descriptive links such as “download the request form” or “check the requirements before you submit”;
a PDF attached as a secondary, print-friendly version;
the same core information in both formats.

The change is not cosmetic. The content becomes easier to use, easier to update, and easier to verify.

What to check in the real world

If your team is deciding whether a PDF is acceptable, ask four concrete questions.

1. Can the document be understood without the original layout?

If a user cannot follow the content when headings, images, and sidebars are removed from the visual context, the structure is too fragile.

Check: a person should be able to jump from section to section and still understand the sequence.

If it fails: move the content into HTML or rebuild the PDF with a real semantic structure.

2. Does the reading order match the logic of the page?

A visually attractive layout can still be unreadable if the underlying order is wrong.

Check: title first, then summary or introduction, then steps, then supporting details.

If it fails: reduce layout complexity and rebuild the content hierarchy.

3. Are links and actions explicit?

A link should tell the user where it goes or what it does.

Check: avoid generic labels like “more” or “here” when the link is part of a task.

If it fails: rewrite the link text so it is meaningful out of context.

4. Are the HTML and PDF versions still aligned?

If you maintain both formats, they need to stay synchronized.

Check: dates, steps, contact points, and constraints should match.

If it fails: define one source of truth and generate the other version from it, rather than editing two separate copies by hand.

A mini acceptance checklist for teams

Use this as a final gate before publishing a document that exists in both HTML and PDF.

The HTML page contains the full content.
The PDF is clearly secondary or supplementary.
The headings describe the content, not just the layout.
The links are understandable without surrounding context.
The reading order makes sense from top to bottom.
Tables are used for data, not for visual positioning.
The PDF and HTML versions match in the facts that matter.
Someone has checked the file with keyboard-only navigation or another accessibility review method.

This is a limited operational check, not a full compliance audit. It tells you whether the document is safer to publish, not whether your entire digital environment is compliant.

What to do when the PDF fails the test

If the PDF is difficult to use, there are three realistic responses:

Keep the PDF, but redesign it properly. This works when a fixed-format document is genuinely needed.
Move the content to HTML and keep the PDF as a copy. This is often the best option for service information, guides, and documents that change.
Remove the PDF entirely. This is the right choice when the PDF adds no value and only duplicates a better web page.

The key is not to defend the PDF because it already exists. The key is to preserve the user task.

The decision should follow the task, not the file format

A document is not accessible because it is a PDF, and it is not inaccessible because it is a PDF either. The real question is whether the content can be consumed, navigated, and acted on without friction.

That is why the W3C framework is useful: it shifts attention from file type to usable structure and perceivable information. For business teams, that shift is practical. It helps answer questions such as:

Which version should customer support rely on?
Which format is easier to keep updated?
Which version is safer for users who rely on assistive technologies?
Which format should be the main reference when content changes?

When those answers are clear, the content strategy is clearer too.

When to involve an accessibility review

Bring in a review when the document is:

part of a customer journey;
used to explain a process or policy;
distributed externally;
updated frequently;
likely to be read on mobile or with assistive technology;
tied to legal, contractual, or service obligations.

In those cases, an accessibility check is not a nice-to-have. It is part of making the service usable.

If your team needs a practical review of documents, page structure, or service content, start with Digital accessibility for websites, software and business workflows. If you also need to build repeatable internal skills around content, workflows, and checks, Academy, workshops and R&D can help frame the team’s method. For content-heavy services and publishing workflows, Digital content and immersive experiences is the most relevant path.

The practical takeaway is simple: use HTML for the content people must act on, and keep PDF as a deliberate support format when it has a clear purpose.