PDFs are not accessible, so why are they still a thing?

Why are PDFs still such a big deal?

How can we encourage content producers to stop making PDFs?

Is it as simple as saying “stop using PDFs” or do we need to do more?

1 Like

I think it starts with having (or assuming) a print requirement such as a brochure or a report. It can also be that customer service teams hand out or send a printed version of the information, checklist or form to customers and the web page looks rubbish when you print it so they create a PDF.

The time and effort is put into designing the PDF, but nobody thinks about the digital requirements, so they just upload the PDF as is. Chances are it duplicates or contradicts content on the website.

So yes, “stop using PDFs” is a good start. We also need to:

  • create or update the online content at the same time as the print version

  • have an acceptable print layout for web pages built into the system and

  • offer online versions of all our forms (big job!).

And there are so many downsides to PDFs. The UK’s NHS provides excellent guidance. They’re not good on mobile and I don’t think they work with browser-based translation tools either. Not sure they’ll work with voice assistants either. Not just not accessible… not usable!


Great points Jennifer. Agree not so easy at the ‘coal face’. Government has mountains of PDFS and yes, some are needed in that format.

If we could all just start from scratch now applying some simple rules - that consider all our users. We would make a difference, step by step.

I love that the UK Govt is this year going to make it a legal duty to meet accessibility requirements. https://gds.blog.gov.uk/category/accessibility/

NSW is also working towards being respectful in its use of PDFs. See the design system standards for accessibility and inclusivity on PDFs.

1 Like

This seems very team and department dependent. One thing we’ve learned with RMS is that a printed version is a requirement due to their audience groups.

Prison inmates are actually in the top 3 audiences for some of their content, but for obvious reasons, do not have access to phones or computers. They must read guides and other handbooks in printed form, so the PDF that is created is also printed as a booklet that can be handed out. In this use case, PDFs are necessary.

I would say it is up to design teams to push stakeholders and other business units to objectively consider if a PDF is necessary or if the information can be provided in other ways.


Agree @brian_helium that printed copies are sometimes absolutely necessary, particularly for all kinds of vulnerable people in our community. It doesn’t mean it has to be a PDF.

We used a plug-in for the Revenue website so that HTML pages print nicely. We didn’t spend the money to further customise the layout, but it can be done. And maybe it’s more economical for us to make HTML pages print better than to spend extra $$$ on separately designing a PDF.

Creating a single source of truth has all those added benefits too.

On a related topic, I noticed that our guidance on linking PDFs recommends the following format:

Download and complete Relationship Certificate Application – PDF.

But here’s what Qld gov has to say:

File type and size must be included in the hyperlink for non-HTML documents.

My understanding is that the file size is also necessary for accessibility and usability, particularly if people have limited data. And I’m not sure that including an n-dash is helpful to people using screen readers. Thoughts?

1 Like

I think we should add a print pattern to the design system to cater for printing our HTML content in a print friendly manner.


@jennifer.weiley agreed that file size and format are required. We did quite a bit of testing around minus, M-dash and N-dash screen reader outputs and found very unexpected results (when associated with a number, minus isn’t read out as a negative, but dash is). I think we need to do some further research in this area


I think @brian_helium helps us see that prioritising accessibility requires us to really think about the different contexts that people engage with out content.

I also agree with @jennifer.weiley that ensuring HTML prints nicely seems to kill a bunch of birds with one stone.

Thanks for your contributions!


Hi everyone,

Very late to this discussion, but here are my thoughts on the issue in no particular order:

Forms still remain a common use case for PDFs, at least in my department - they are mostly used in cases where signatures are required. Unfortunately, most of the time, the person filling in the form is expected to print the form, sign it, then scan it back in - defeating the purpose of collecting information electronically.
It is very difficult and fiddly to produce a proper interactive PDF form, even when you do know what you’re doing (says someone who has spent more time with tag trees than he would have liked!)

You can’t upload a PDF into your website and expect everyone to have the same experience with it because every browser treats PDFs differently. Some just download the PDF file, but most of them these days use their own PDF viewer plugin, which may or may not recognise the tagged or interactive elements in the ways that Adobe’s plugin would have done.

Generally speaking, I feel content producers need to be encouraged to stop thinking in terms of appearance, and think more in terms of structure - how information is organised rather than how it looks. Get the structure right, and appearance will usually take care of itself.


Hey Mike!

Thanks for joining the discussion!

I’ve been trying to figure out how to make PDF’s accessible (and struggling) so I get some of your struggle.

I really think it’s a valuable point surrounding the browser.

The last point that you make remains, the responsibility is on content producers to creat good structures.

Hi @mike.hall - I would love to see a print pattern added to the design system. I reckon we could instantaneously delete about half of our PDFs if the web pages printed nicely.

Another initiative that would help reduce the reliance on PDFs would be a long document template for publication of reports, legal judgements and other structured documents. This usually includes a sticky nav element with a list of the chapter headings (H2, H3) or separate pages with previous/next navigation. We would also need to provide an option to print the whole document if required.

Long document examples:

Thanks Jennifer. I think there’s a basic CSS print already.

@mason.phan can you confirm? Could you also add a more complex one to the backlog?


Here’s another example @mason.phan and @mike.hall of the long document format from Mass.gov: Sales and use tax.


Thanks Jennifer,

We’ll use this as one of the working examples if that’s OK.


1 Like