Think your PDF is accessible? Think again.

Document icon with an audio speaker, in front of a computer iconPDF is the most popular document format for sharing information online. According to the latest CommonCrawl data, PDFs account for almost 1% of all links on the internet – more than any other file format apart from HTML (the file format of webpages).

While government departments, educational institutions and organisations are slowly shifting towards HTML as the format for sharing information online, PDF is still the default way to share a digital version of a print document.

Despite the tools and resources available to make PDFs accessible, screen reader users still have an unfavourable view of the format. In WebAIM’s Screen Reader User Survey of 2019, 75.1% of respondents indicated that PDFs are very or somewhat likely to pose significant accessibility issues.

In this article, we’ll introduce tagged PDFs and then discuss one of the main factors undermining PDF accessibility – how well PDF viewer applications work with screen readers.

PDFs and accessibility

PDF is the most popular document format for sharing information online. It has been around as a document format since the early 1990s. Because it was introduced as a way to share digital versions of print documents, it did not initially include support for assistive technology such as screen readers.

To address the needs of people who use assistive technology, the PDF Association introduced the PDF/Universal Accessibility standard (PDF/UA). PDF/UA sets requirements for:

  • accessible PDF documents
  • PDF reader applications
  • screen reader software.

Since the PDF/UA standard was published in 2012 it has become possible to add information to PDF documents so that they can work better with assistive technology, including screen reader software. Making a PDF document accessible can involve:

  • ordering the ‘tags’ of the PDF, which tells assistive technology the correct order to announce the content in a logical way
  • adding meaningful alternative text to images, so that screen reader users don’t miss out on the information in images
  • using heading levels (e.g. H1, H2, H3) to communicate the hierarchy of headings and subheadings in the document, like a table of contents
  • adding well-structured tables with header cells, so the table data is properly labelled for screen reader users.

To see what it is like to read a tagged PDF with a screen reader, you can view a video recording below of a user reading a tagged PDF with Adobe Acrobat Pro DC and the NVDA screen reader on Windows 11:

The accessibility of the PDF depends on more than the document itself

When a person is using screen reader software to read a PDF, the accessibility of the experience depends on:

  • the accessibility of the PDF document itself
  • how well the PDF viewer (e.g. Adobe Acrobat, built-in PDF viewer inside web browser) communicates the document information to the screen reader application being used
  • how well the screen reader (e.g. JAWS, NVDA, VoiceOver) announces the content.

As content authors we have full control over the PDF document itself, but we don’t have control over which PDF viewer application and screen reader software the audience is using.

Comparing how well PDF viewer applications work with screen readers

To get a better idea of how well PDF viewer applications communicate information in the document to screen reader software, we tested different PDF viewer applications with screen reader software.

We created a simple test PDF with:

  • headings, including H1, H2 and H3
  • content organised in a different visual order compared to the tag order, so we could test the sequence the screen reader followed
  • an image with alternative text
  • a table with header cells.

You can download the test PDF here.

We tested each PDF viewer application with different screen reader software. On Windows, we used JAWS and NVDA. On macOS, we used the built-in VoiceOver software.

What we tested

  • Content is announced in the correct order – it should follow the order of the ‘tags’.
  • Heading levels – when announcing a heading, it should announce the heading level, which should match the type of the heading tag.
  • Image alternative text – the alternative text of an image should be announced, along with a label to show that it is an image e.g. ‘graphic’ or ‘image’.
  • Tables – it should announce the table as a table, and allow the user to navigate around the cells one at a time. The data cells should be labelled by the header cells.
View the full results table
PDF viewer application Correct order Headings Image alternative text Tables
Google Chrome (version 101, Windows 11) - built-in PDF viewer

Recording on YouTube
❌ Follows the visual stacking order of the page, not the tags ❌ Inconsistent - announces H1, H3 and paragraph as H2 ❌ Skips the image, and then announces an ‘unlabelled graphic’ at the end of the alternative text, despite the alternative text being set on the image ❌ Merges row cells together (e.g. “Name operating system website”), does not announce as a table
Microsoft Edge (version 101, Windows 11) - built-in PDF viewer

Recording on YouTube
❌ Follows the visual stacking order of the page, not the tags ❌ Inconsistent - announces H1, H3 and paragraph as H2 ❌ Announces the alternative text in the correct place, but merges with the heading below (e.g. “Graphic PDF logo section with a table”) ❌ Merges row cells together, does not announce as a table
Firefox (version 100, Windows 11) - built-in PDF viewer

Recording on YouTube
✔️ Follows the tags ✔️ Consistent with tags ❌ Skips image with alternative text ❌ Announces as a table, but when announcing the first column cells, it repeats the previous cells in that column (e.g. it announces the TalkBack cell as “Row 4 VoiceOver NVDA JAWS column 1 TalkBack”)
Adobe Acrobat Pro DC (version 2022.001.20117, Windows 11)

Recording on YouTube
✔️ Follows the tags ✔️Consistent with tags ✔️ Announces as a graphic, and announces alternative text in the correct place ✔️ Announces as a table, and the cells are labelled by the headers
Preview (version 11.0, macOS Monterey)

Recording on YouTube
✔️ Follows the tags ✔️Consistent with tags ✔️ Announces as an image, and announces alternative text in the correct place ✔️ Announces as a table, and the cells are labelled by the headers. VoiceOver uses one voice to announce the label, and another to announce the content
Safari (version 15.4, macOS Moneterey) - built in PDF viewer

Recording on YouTube
✔️ Follows the tags ✔️ Consistent with tags ✔️ Announces as an image, and announces alternative text in the correct place ✔️ Announces as a table, and the cells are labelled by the headers. VoiceOver uses one voice to announce the label, and another to announce the content

Note: Google Chrome and Microsoft Edge have very similar results because they are both based on the Chromium project. While they have a different look and feel, both browsers have the same core PDF viewer technology.

What content authors can do about this issue

While content authors cannot control which PDF reader application users choose to use, there are a couple of things that we can do to improve the user experience.

1. Offer alternative formats such as HTML and Word

We believe the most accessible way to share information online is by publishing it as a webpage. Web browsers are more consistent in communicating HTML (the format of the web) to screen reader software. Webpages also load faster, work on more devices, reflow content for smaller screens and are better for search engine optimisation.

Publishing information as a webpage does not require expert knowledge of HTML or coding. If you know how to add a new page to your website, you can copy and paste content from a document into your content management system and publish a new page.

Another format to consider is a Microsoft Word document. In WebAIM’s Screen Reader User Survey of 2021, 68.9% of users said they find Word documents to be the most accessible document format. While Word documents are not as flexible as webpages, they can be a good way to share simple documents.

2. Include a disclaimer when linking to PDF documents

Because this is not a well-known issue, we can’t expect our end users to know the differences between PDF viewer applications.

If a screen reader user follows a link to your tagged PDF but uses a PDF viewer that does not communicate the content properly, the accessibility work has been undone.

To let users know about this issue, you can include a disclaimer when you link to a PDF document, such as ‘If you are using assistive technology, we recommend using Adobe Acrobat to read the document, rather than your web browser’s built in PDF viewer.’

More resources

We hope this article gives you a good idea of the state of things when it comes to PDF accessibility and the different PDF viewer applications.

Please reach out to the Information Access Group if you would like to talk to us about this issue or want to learn more about how you can make your information more accessible.

Here are some helpful resources if you would like to learn more about this issue: