Word, PDF, HTML. The accessibility of consultation documents
We hosted the Consultation Institute Coffee Morning on Thursday 8 October and there was a lively discussion about the correct format of consultation documents to ensure they are accessible and meet legal duties.
We’ve gone away and done some extra research to produce this guidance for engagement and consultation practitioners. Let’s start with some basics, before summarising what various regulations and guidance say before giving you information that will help you make decisions in your organisation.
Basics
Word
A Word document is a file created in Microsoft Word, usually saved with the .docx extension. It is designed to be written, edited and shared, which is why it is the starting point for most consultation documents. Word documents can be opened in Word or in free alternatives such as LibreOffice or Google Docs, though the layout can shift slightly depending on the software and device used. When built in an accessible way, the structure is used by screen readers and carried across when the document is turned into HTML or PDF. That is what makes Word such a useful foundation for accessible publishing.
A PDF, short for Portable Document Format, is a file designed to look the same wherever it is opened. It is usually created by exporting or printing from another program, such as Word, rather than written from scratch. That makes it a good choice for documents people need to print, attach to an email or refer to by page number. PDFs can be opened in a web browser or in free readers such as Adobe Acrobat Reader, and the layout stays fixed whatever the device. That reliability has a cost: the text does not rewrap to fit a phone screen or a larger font size. Behind the visible page, a PDF can contain "tags" that tell a screen reader which parts are headings, lists, tables and images, and in what order to read them. Those tags are mostly carried over from a well-structured Word document when it is exported. If the source document wasn't structured, the PDF won't be either.
HTML
HTML, short for HyperText Markup Language, is the language web pages are written in. It is not usually saved and sent as a file. It is published on a website and read in a web browser on any computer, tablet or phone. HTML is built to adapt to the reader: text rewraps to fit the screen, and people can apply their own settings for text size, colours and fonts. Behind the visible page, HTML marks each part of the content for what it is: a heading, a list, a table, a link or an image with its description. That structure must be put in deliberately, though, and a web page converted from a badly structured document can look fine while being hard to use with assistive technology.
What the law and guidance say about accessible consultation documents
The law requires accessible content. “HTML only” comes from guidance or local policy. Organisations can also use the disproportionate burden process to explain where producing an HTML version is not reasonable, provided they still meet their legal duties and offer accessible alternatives. Let’s separate five different things that sometimes get blurred together.
Source | What it is | What it says about formats |
Public Sector Bodies Accessibility Regulations 2018 | Law | Websites, apps and their content must be perceivable, operable, understandable and robust, measured against WCAG AA (for public sector bodies). There is provision for a disproportionate burden assessment. No rule that every document must be HTML. |
Equality Act 2010 | Law | Public bodies must make reasonable adjustments, anticipating needs rather than waiting to be asked, and have due regard to equality under the Public Sector Equality Duty. This is where alternative formats on request come in. |
Web Content Accessibility Guidelines (WCAG) 2.2, Level AA
| International technical standards | The yardstick public sector websites, apps and documents are judged against. The Government Digital Service monitors a sample of public sector sites each year against WCAG 2.2 AA. WCAG applies to the content, whatever the format, so it covers Word and PDF documents as well as web pages. GOV.UK also says that failing to meet the accessibility requirements means failing to make reasonable adjustments under the Equality Act. |
UK Government: Publishing accessible documents | Guidance | "HTML is the most accessible format for publishing documents. It should be your first choice whenever possible." A new PDF should be a last resort unless there is a specific business need, with an HTML version alongside. |
Your organisation's publishing policy | Local policy | May be stricter than the law, for example "every attachment needs an HTML version". That is a legitimate choice, but it is a policy, not a statute. |
Table 1: Law vs guidance vs policy
The UK Government guidance sets a strong preference for HTML, and the phrase "unless there is a specific business need" is doing real work. It does not amount to a legal ban on accessible PDFs.
Why The UK Government prefers HTML
HTML is the language web browsers and assistive technology are built around, so a well-made web page adapts to the reader rather than the other way round. The UK Government has been clear about this since a 2018 blog post explaining why government content should be published in HTML and not PDF.
How screen readers work with HTML
Most screen reader users do not listen to a page from top to bottom. They skim it, much as a sighted reader scans headings. On a well-structured web page they can:
pull up a list of every heading and jump straight to the section they want
move between landmarks such as the main content, navigation and footer
bring up a list of all the links on the page
hear table data with its column and row headers read out
fill in forms where every box is announced with its label
All of this works in the browser they already use, with the settings they already rely on. With a PDF, the same features depend on the document having been tagged correctly, and on which PDF reader and screen reader the person happens to be using. Even a well-made PDF can behave differently from one set-up to the next. As the Government Digital Service (GDS) put it, "there's still no guarantee that PDF content will meet the accessibility needs of users."
It is not only about screen readers
Zoom and reflow. HTML text rewraps when someone zooms in or reads on a phone. A PDF keeps its page shape, so magnified text often means scrolling sideways along every line.
Personal settings. People who change colours, fonts or text size, or use reader view or browser translation, can apply those settings to a web page. They are much harder to apply inside a PDF.
One current version. A web page can be corrected in place. Downloaded PDFs carry on circulating after they are out of date.
Staying on the page. A PDF often opens in a separate app or downloads to a folder, taking people away from the consultation page and the link to respond.
Knowing what works. Teams can see how people use a web page. Once a PDF is downloaded, that insight stops.
The catch, as the next sections explain, is that all these benefits depend on the page being built properly, and that a web page is not always what people need in their hands.
Word, PDF and HTML compared
Word | HTML | |
For documents people edit. | For fixed, printable copies. | For web. |
Familiar to most people. Has a built-in accessibility checker that is improving – but doesn’t pick everything up.
It is weak as a formal final version for any consultation documents as it is editable. Needs software to open and layout varies by device.
The document owner needs to build the document in an accessible manner (more on the importance of this below). | Provides you with stable page numbers, and it prints and emails well which you may want to do in a consultation. It is a self-contained formal copy.
If an accessible Word document has been converted to PDF, the tags should follow through but you may still need to do some manual fixing of tags.
If you are starting from scratch in Adobe, it is quite time consuming and complex to do the accessibility manually (though not impossible with training!)
| Reflows on any screen and respects personal browser settings. Easy to update. Online version only.
As with the other formats, only as good as it is built. If you are starting with a Word document and converting to HTML it will try and guess some of the structure, e.g. if you have made something bold and bigger it might assume it is a heading – but you will need to manually check. It is not a “magic accessibility fix”.
Hard to email or print – which are things you may want to do in a consultation. |
Table 2: Word, PDF and HTML compared
The foundation is an accessible Word document
As we have thought this through in a structured manner, it has reminded us that the foundation matters before you even decide whether you then want a PDF or HTML (or both!).
A well-structured source Word document can become a good HTML or good PDF – a poor source document will produce a poor version of both.
So, to reiterate:
HTML is not automatically accessible – a badly built page can fail keyboard and screen readers just as badly as any PDF
PDF is not automatically inaccessible – a properly tagged PDF made from a well-structured source can work well.
Start with Word
Whatever format you finally publish in, the accessibility is mostly decided while the document is being written. That is why good Word habits are the place to start.
Accessible Word is not really about Word. It teaches authors to think about structure rather than appearance, and that way of thinking carries straight into HTML and PDF.
In Open Voice Lab’s “House Rules of Accessible Word Documents” training we liken building an accessible Word document to building a house, covering:
The brief – knowing what document you are building and who it is for
The blueprint – setting your structure so people can move around your document as they need too.
The build – making sure your content is plan English, non-jargon
The decoration – Your design flourishes which include the use of links, tables, images, colour
The finish – how you check your accessibility (before you do anything else with your document)
Then decide: HTML or PDF (or both!)
Once the source is properly structured, the format question becomes much easier. Default to HTML for anything people will read online only. A PDF may be more suitable if you need a version of documents people need to print or forward.
In an ideal world, engagement teams would publish every document in every format and language required. In practice, teams must make proportionate, defensible decisions and be able to explain their decisions.
A practical catch with HTML
A HTML is not a document you can hand to someone. You can send a link, but you cannot attach an HTML page to an email and expect it to arrive looking right, and printing a web page often gives patchy results: navigation menus, cookie banners and awkward page breaks all come along for the ride.
That matters a great deal in consultations, because so much of the reach happens through other people:
a community group or charity emails the document on to its members
a GP practice, library or community centre prints copies for people who are not online
a support worker reads it through with someone at a kitchen table
a committee or partnership board wants a paper pack with page numbers to refer to
someone with a poor connection, or no data left, wants to download it and read it later
The question is whether this is the “specific business need” that the UK Government guidance allows for. Public bodies also have scope to justify their choice through a disproportionate burden assessment, where the cost, practicality or impact of producing an HTML version would be unreasonable. Whatever you decide, record the rationale clearly.
Ask the people who will use it: a readers panel
The best way to settle the format question is to ask the people who will read, share and respond to the consultation. A readers panel turns accessibility from a technical check into a conversation with your audience.
A readers panel is a small group of people who review your materials before they go live and tell you what works for them. In an ideal world every public sector body would produce every consultation document in every language and format anyone could ever want – but this isn’t often realistic due to resource constraints. Working some of these decisions through and testing formats with a readers panel could help you make better decisions.
In conclusion: accessibility at source, format by purpose
HTML, Word and PDF are not competing badges of accessibility. They do different jobs. HTML is the right default for the web, but the accessibility of any document comes from its structure, its clarity and the checking done before it goes out. You also need to consider what you need your documents for in the consultation and what makes most sense to produce.
Open Voice Lab
The Open Voice Lab team has spent many years working in NHS and public sector communications, so we know how much pressure teams are under and how confusing advice on accessibility can be. If you’d like to talk through anything in this briefing, or if you want information about our training or our help with producing documents to take this off your hands, we’d be glad to hear from you.
Important note
This briefing is a guide based on our understanding of current information about accessibility, not legal advice. If you think we may have got something wrong, please challenge us – our aim is to offer useful information to the engagement and consultation community, and if we learn something new we are more than happy to update our guidance. Don’t hesitate to get in touch!
Sources
Comments