Making PDFs Accessible on Public Sector Websites

Making PDFs accessible on a public sector website starts with deciding whether the document should be a PDF at all. GOV.UK guidance treats HTML as the first choice and a PDF as the exception, so the work usually splits into replacing documents that belong on a web page and properly tagging the ones that have to stay. Both sit within the wider duties covered by website accessibility for public sector bodies, which apply to downloadable documents as much as to the pages that link to them.

The sections below follow the order a publishing team would normally work in. They cover what an accessible PDF is, which documents the regulations cover, how to fix the source file and the PDF itself, how to test the result and how to record anything that still fails in the accessibility statement.

What Makes a PDF Accessible

A PDF is accessible when assistive technology can read its content in a logical order and understand its structure, which in practice means the file has to be tagged. WebAIM’s explanation of PDF accessibility describes tags as the layer that holds the headings, links, lists and tables. The same page states plainly that an untagged PDF would not be considered accessible.

Tags do not change how the document looks. They sit behind the visual layout and tell a screen reader that a line of large text is a heading, that a picture needs a text alternative or that a grid of numbers is a data table with header cells. A PDF can look perfectly clear on screen and still be unreadable to someone who cannot see it, which is why a visual check on its own tells you very little.

Tagging is the minimum rather than the whole job. The document also needs a meaningful title in its properties, a reading order that matches the visual order, text alternatives for images and enough colour contrast for the text to be read comfortably.

Why GOV.UK Recommends HTML Before PDF

GOV.UK recommends HTML because a web page works with the browser settings, screen readers and devices people already use, while a PDF often does not. The guidance on publishing accessible documents says to publish in HTML wherever possible and describes creating a new document as a PDF as a last resort, to be avoided unless there is a specific business need.

The same guidance says an HTML version should always be published alongside a PDF on other government websites. It also states that PDF and PDF/A cannot be made fully accessible to all users of assistive technology. A publisher who keeps a PDF on GOV.UK is legally required to publish an accessible version with it.

The Government Digital Service set out its reasons in a blog post on why content should be published in HTML and not PDF. PDFs do not resize to fit the browser, take people away from the website they came from, are less likely to be kept up to date and limit the changes users can make to colours and text size. Even a carefully tagged PDF can still let some readers down for those reasons.

On a WordPress website, most reports, policies and guidance notes can be published as ordinary pages with proper headings, which removes the tagging work altogether. Priority Pixels develops WordPress websites to WCAG 2.2 AA as a baseline and provides training so internal teams can keep publishing to that standard. The page on WordPress websites for public sector organisations describes how automated tools and manual audits are used before launch.

Which PDFs the Accessibility Regulations Cover

The accessibility regulations cover every PDF a public sector body publishes on its website from 23 September 2018, along with older documents that people still need to use a service. Regulation 4 of the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 exempts office file formats published before that date unless the content is needed for active administrative processes. The same regulation defines office file formats to include Adobe PDF, Microsoft Office documents and their open source equivalents.

GOV.UK guidance on the accessibility requirements for public sector websites and apps gives a form for requesting school meal preferences as an example of an older document that still has to be fixed, because people need it to use a service. The same page says covered content should meet WCAG 2.2 AA and that anything left inaccessible because it is exempt has to be explained in the accessibility statement.

Being outside the regulations does not remove every duty. GOV.UK points out that exempt organisations and content are still subject to the Equality Act 2010, so a person who cannot read an older PDF can ask for the information in another format and the organisation has to make a reasonable adjustment.

Our overview of website accessibility law in the UK covers how the regulations and the Equality Act fit together. Keeping a dated list of published documents makes the exemption much easier to apply, because the publication date decides which row of the table a document falls into.

Start With an Accessible Source Document

The most reliable way to produce an accessible PDF is to fix the source document in Word or another office program before exporting it, because the tags are generated from the structure already in the file. GOV.UK advises making the source document accessible before converting it, then running an accessibility checker on the PDF to catch anything that was missed.

Styles do most of the work in the source file. A heading set with the Heading 2 style becomes a heading tag in the PDF, while a line of bold text in a larger font becomes an ordinary paragraph that a screen reader user cannot jump to.

The GOV.UK checklist for documents that cannot be published as HTML covers the same points every time. Before exporting, check the following in the source file.

• Headings use the built in heading styles, start at Heading 1 for the title and never skip a level
• Every informative image has alt text and decorative images such as divider lines are removed
• Tables are used only for data, with a header row and no split or merged cells
• Link text describes where the link goes rather than saying here or more
• Colour contrast is checked and meaning never depends on colour or shape alone
• Text is not set inside images and the file name is short and describes the document

The export method matters as much as the content. WebAIM’s advice on converting documents to PDF warns never to create a PDF with the Print option, because the heading structure, alternative text and other tags are lost. Saving or exporting as a tagged PDF keeps the structure the styles created.

Repairing Tags, Reading Order and Alt Text in Acrobat

When the source file has gone or the PDF came from a third party, the tags have to be repaired directly in the PDF using Adobe Acrobat Pro. WebAIM’s notes on setting up Acrobat for accessibility work explain that the Accessibility tags panel, the Order panel and the accessibility tools are not visible by default and have to be added to the workspace first.

The repairs usually fall into four areas. Each one is checked against the visual page, so the person doing the work compares what the tags say with what a sighted reader sees.

Repairing a long PDF by hand is slow and has to be repeated every time the document is updated, because a fresh export from the source replaces the fixed tags. For any document that changes regularly, fixing the source file or moving the content onto an HTML page avoids making the same repairs again.

Making Tables and Forms in PDFs Usable

Tables and forms in a PDF are usable when every data cell is linked to a header and every form field has a label that a screen reader can announce. GOV.UK advises using tables only for data, keeping them simple and avoiding split or merged cells, with header cells marked as table headers so each value is read with its column name.

Forms need more work than tables. WebAIM’s page on accessible forms in Acrobat explains that a visible label in a PDF form is not directly linked to its field, so the label has to be repeated in the tooltip that screen readers announce. The fields also need tags and the tab order has to be checked by hand.

A form that people need to apply for a service is the clearest case where the exemption for older documents does not apply. Replacing it with a web form is usually quicker than repairing the PDF and gives a better result for everyone who uses it.

Testing PDFs With PAC, Acrobat and Screen Readers

A PDF is tested by combining automated checks in Acrobat or PAC with a manual review using a screen reader, because automated tools can confirm that tags exist but not that they make sense. A checker can report that an image has alt text, for example, without being able to tell whether the text describes the image correctly.

The PAC PDF Accessibility Checker is free to download and checks many PDF/UA and WCAG requirements at once. Running it alongside the Acrobat check gives a second opinion before the manual screen reader review, which is the step that shows whether the document makes sense when heard rather than seen.

Testing documents should sit inside the same routine as testing pages. Our guide to what a web accessibility audit tests lists untagged PDFs among the common failures found when a whole website is reviewed.

Listing Inaccessible PDFs in the Accessibility Statement

Any PDF that still fails WCAG 2.2 AA has to be listed in the accessibility statement, in the section that matches the reason it has not been fixed. The GOV.UK sample accessibility statement splits that content into failures against the regulations, problems claimed as a disproportionate burden and content outside the scope of the regulations. It also says those subheadings are legally required and should not be changed.

Older documents that are not needed for a service go under content outside the scope of the regulations. The sample wording says the regulations do not require fixing PDFs published before 23 September 2018 that are not needed to provide services, then gives an example of a document that will not be fixed.

Newer PDFs that fail belong in the failures section, with the problem, the WCAG success criterion it fails and the date the fix is planned. A claim of disproportionate burden needs an assessment carried out before it is made and should be looked at again when circumstances change.

The statement should also give contact details for requesting a document in another format, such as an accessible PDF, large print or an audio recording. It has to be reviewed at least once a year, so the document list should be checked at the same time against everything published since the last review. Our guide to writing an accessibility statement covers the rest of the required wording.

Over time the list of failing PDFs should shrink rather than grow. Publishing new content in HTML, fixing the documents people need for services and recording the rest accurately is the direction both the regulations and the GOV.UK guidance point towards.