GOV.UK and PDF accessibility

5 December 2017 | Ted Page


The information on the GOV.UK page referred to below has, thankfully, been replaced with some good basic information on making PDFs and other documents accessible. We will retain this post for reference purposes.


This post revisits the subject of PDF accessibility myths, and why challenging such myths matters. It will argue that the problem of inaccessible PDFs is not the format itself, but the widespread lack of knowledge as to how to author them properly. Failure to understand this crucial distinction is itself an accessibility problem. 

Google the term “pdf accessibility”

If you Google the term “pdf accessibility” (at least in the UK), the following will appear, typically within the top 5 results on the first page.

Google pdf accessibility results page extract
Extract from a Google results page for the search term “pdf accessibility”

Three statements that need to be challenged

The text in the above screenshot mirrors the key text on the page that it links to on the GOV.UK website (updated as recently as 11 November 2017):

PDFs are bad for accessibility. Users can’t customise them for ease of reading, and they don’t work so well with assistive technologies like screen readers.

Screenshot of the GOV.UK page
How to publish on GOV.UK

These 2 sentences make 3 different claims, each of which we will examine in turn.

Statement 1: PDFs are bad for accessibility

This statement is incorrect. With one or two exceptions, it is possible, if you know how, to make PDFs that conform to all of the applicable WCAG 2.0 and PDF/UA criteria, and that work seamlessly with all of the major assistive technologies (see statement 3 below for more on the latter). The exceptions referred to above do not undermine the point at all: as will be seen, all formats have both strengths and weaknesses in this respect, including HTML.

Statement 2: users can’t customise them for ease of reading

This statement is also incorrect. There are two important ways in which PDFs can be customised for ease of reading, namely reflow view and colour customisation. 

Reflow view

With the exception of PDF forms, you can reflow any correctly authored PDF. In reflow view you can increase the font size as much as you want, with no horizontal scrolling. This is particularly useful in the case of multi-column layouts. To toggle reflow on or off, press Ctrl + 4 on Windows, or Cmd + 4 on a Mac. (For fun you can also try toggling Ctrl/Cmd + Shift + H in conjunction with reflow view to create your own pseudo-autocue, controlling the scrolling speed with the number keys along the top of the keyboard, but I digress.) 

Colour customisation

Provided that a PDF has been authored correctly, and with the exception of PDF/A-compliant documents, you can also customise text and background colours in any combination (Edit/Acrobat, Preferences, Accessibility, Document Colors Options). 

Some limitations in access to typographic style

Whilst it is certainly true that some aspects of access to typographic style are not as good in PDF as they are in HTML, it is also true that other aspects of PDFs are more, and sometimes much more, accessible than their HTML counterparts. We will expand on this vitally important point in much greater detail in a series of forthcoming posts and videos on this site. But for now, suffice it to say that all formats have their imperfections in this respect, and that includes HTML.

Statement 3: they don’t work so well with assistive technologies like screen readers

Finally, this third and last statement is also incorrect. We routinely test PDFs for accessibility with up to 12 different assistive technologies (depending on the nature of the content), and have done so for many years. These assistive technologies are:

Screen readers: JAWS, SuperNova, NVDA, VoiceOver, TalkBack

Screen magnifiers: ZoomText, SuperNova, MAGic

Literacy software solutions: Read&Write Gold, Claro Read, vBookz PDF Voice Reader

Speech recognition: Dragon Naturally Speaking

Far from not working “so well with assistive technologies”, once again, provided that a PDF is properly authored, it should work correctly across a wide range of assistive technologies. Any PDF that does not should be the exception (such as a map or perhaps a music score), not the rule.


Different formats suit different types of content and different people (in some cases, Microsoft Word will work better than either HTML or PDF). There is no one-size-fits-all solution. The “problem” of inaccessible PDFs is not the format. It’s the widespread lack of knowledge as to how to author them properly.

Furthermore, the statement that PDFs are “bad for accessibility” is itself bad for accessibility, especially when it is contained in so prominent a document. If people believe that PDFs are somehow inherently inaccessible they are less likely to try make them accessible, and the end-user will suffer.