Documents Left Behind: Moving UK Public Sector Publishing from PDFs to HTML

PDFs are still the default output for a great deal of UK public sector publishing. Board papers, inspection reports, tenant handbooks, patient leaflets, planning notices, and consultation documents are routinely produced in Word or InDesign and exported as PDF. The format is familiar, portable, and embedded in workflows that predate the web. It is also one of the most persistent accessibility gaps in councils, NHS trusts, and central government agencies.

The problem is not that PDF is inherently unusable. A well-made PDF can be accessible. The problem is that most PDFs are not well made, and the effort required to make them accessible is often invisible to the people commissioning them. When documents are published at volume, the gap between the ideal and the default becomes a systemic barrier.

Why the PDF habit survives

Public sector teams often inherit PDF workflows rather than choose them. A report is written in Word, signed off by a committee, exported to PDF, and uploaded to a content management system. A leaflet is designed in InDesign, checked by a communications team, and published as a print-ready PDF. A scanned letter is saved as an image because that is what the case management system produces. Each step is rational in isolation. Together, they create a publishing model in which accessibility is an afterthought.

PDF also carries an appearance of authority. It fixes layout, preserves pagination, and gives the impression of a final document. For organisations worried about version control, that can feel safer than a web page that might be edited. But the safety is partly illusory. An inaccessible PDF can be final and still fail the people who need it.

Common failure modes

Most inaccessible PDFs fail in predictable ways. The document may be untagged, so assistive technology cannot determine headings, lists, paragraphs, or reading order. It may be a scanned image with no text layer, which means it cannot be searched, selected, or read aloud. Tables may lack header rows or scope attributes. Forms may be flat images rather than fillable fields. Images may have no alternative text, or may have alternative text that repeats the caption. Headings may be visual only, created with bold text and font sizes rather than structural styles.

Metadata matters too. A missing document title, an incorrect language setting, or an absent content description can make navigation harder. Reading order can be scrambled by complex layouts, text boxes, and multi-column designs. Links may be uninformative, with “click here” repeated dozens of times. Colour contrast may be poor. Multimedia may autoplay without controls. None of these issues is exotic; they are the everyday residue of documents designed for print and exported for the web.

The hidden cost of remediation

Retrospective PDF remediation is expensive, but the cost is rarely captured in one place. It appears as staff time spent tagging documents, external remediation invoices, duplicated effort when a document is updated, and delays when a publication cannot be released until it has been checked. It also appears as risk: a complaint, a failed audit, or a service user who cannot access the information they are entitled to.

The deeper cost is repetition. If the authoring workflow remains unchanged, every new document recreates the same problems. A team can spend weeks fixing a batch of legacy PDFs and then publish a fresh batch with the same defects, because the template, training, and quality checks have not changed. Remediation without prevention is a treadmill.

There is an opportunity cost as well. Every hour spent repairing a PDF is an hour not spent on content design, user research, or fixing the HTML pages that most people actually use. Public sector teams are under pressure; remediation should not become a substitute for a sustainable publishing model.

A step-by-step shift to HTML-first publishing

1. Inventory and risk-assess your documents

Start with a focused inventory rather than a heroic attempt to catalogue everything. Identify the documents that matter most: high-demand leaflets, statutory notices, application forms, reports that support a decision, and content used by people who may be disabled or vulnerable. Record format, age, owner, update frequency, and whether an HTML equivalent already exists. Prioritise by user need and legal risk, not by file size.

2. Set a default policy

Adopt a clear principle: new public-facing content should be published as accessible HTML unless there is a documented reason to use PDF. “Because we always have” is not a reason. “The document is a signed legal notice that must preserve its exact form” may be. The policy should name the exceptions, the approval route, and the accessibility checks required for any PDF that is published.

3. Fix the authoring workflow

HTML-first publishing is not just a content management decision; it is a workflow decision. Provide templates with accessible heading structures, lists, tables, forms, and image handling. Give authors a clear place to add alternative text and a plain-English summary. Remove the habit of exporting a designed document when a web page would serve users better. Where PDFs are necessary, train authors to use built-in accessibility features in Word or InDesign rather than relying on a final check.

4. Build capability, not just guidance

A policy without training will not survive contact with deadlines. Run short, practical sessions for content teams, communications staff, and document authors. Use examples from your own organisation. Show what a screen reader announces when a table has no headers. Demonstrate the difference between a scanned letter and a tagged document. Make accessibility checks part of the publishing checklist, not a separate special project.

5. Provide HTML alternatives for legacy content

Not every legacy PDF needs to be remediated immediately. For high-demand documents, create an accessible HTML version and link to it prominently. Keep the PDF for people who need the original layout, but do not make it the only route. For low-demand archival material, document the decision and provide a contact route for accessible formats. This is a defensible approach if it is transparent and actively managed.

6. Procure with accessibility in mind

Content management systems, form builders, and document management tools should support accessible publishing by default. Ask suppliers how their product handles headings, tables, alternative text, and PDF export. Ask for evidence, not just assurances. Include accessibility requirements in contracts and make remediation support part of the commercial conversation.

7. Monitor, report, and iterate

Track the proportion of new public-facing documents published as HTML, the number of PDF exceptions, and the accessibility issues found in sample checks. Review complaints and user feedback. Publish progress in your accessibility statement. The aim is not a one-off clean-up; it is a publishing system that gets less fragile over time.

When a PDF is unavoidable

Some PDFs will remain. When they do, author them accessibly from the start: use real heading styles, add alternative text, tag tables, set the document language and title, check reading order, and test with a screen reader. Provide an HTML summary or equivalent where possible. Do not assume that a PDF is accessible because it opens without error. The question is whether someone can navigate it, understand it, and complete the task it supports.

The shift to HTML-first publishing is not a rebrand of an old problem. It is a change in default. For UK public sector organisations, the most accessible document is often the one that was never a PDF in the first place.