Accessibility experts have always had a complicated relationship with PDFs. These files remain some of the most popular formats of long-form content online, but present several accessibility and inclusion challenges.

Rather than abandoning PDFs altogether, it can be helpful to understand how they can be made more inclusive, and learn about the contexts in which HTML content may perform better for your organisation and audience.

 

The basics: What makes a PDF inaccessible?

A PDF can look perfectly clear on screen and still create significant barriers for disabled users. The issue often sits beneath the visual design of the document, in the structure that assistive technologies rely on to understand and navigate its content.

Screen readers do not interpret a page in the same way as a sighted reader. They depend on information that identifies headings, paragraphs, lists, tables, images and the intended reading order. In an accessible PDF, this information is provided through tags and an underlying logical structure. However, when that structure is missing or incorrect, the experience can quickly break down. 

PDFs can also present challenges for people who need to enlarge content. WCAG 2.2 includes a Level AA requirement for content to reflow so users can increase its size without having to scroll in two dimensions to read each line. PDFs are based around pages and fixed layouts, which can make this experience less straightforward, particularly on smaller screens or at high levels of magnification. 

None of this means that PDFs are inherently inaccessible. A well-structured, correctly tagged and thoroughly tested PDF can provide an accessible experience. The challenge is that achieving this requires accessibility to be considered during document creation and often requires additional remediation afterwards. Simply exporting a document as a PDF does not guarantee an accessible result.

 

How HTML can help

For content that is primarily intended to be consumed online, HTML provides a more flexible foundation for accessibility.

HTML allows the structure and meaning of content to be built directly into the page. When developers and content editors use semantic HTML correctly, headings, lists, links and other elements communicate their purpose programmatically. Assistive technologies can use that information to help users understand the page and move through it more efficiently.

HTML content can also respond to the way an individual chooses to access it. A well-built webpage can adapt to different screen sizes, reflow when users zoom and respond to browser or device settings. Rather than requiring the user to adapt to the dimensions of a document, the content can adapt around the user. 

There is also a practical advantage for organisations publishing content at scale. Accessibility can be embedded into website templates, components and content management systems, creating a stronger foundation for every new page. By comparison, PDFs often need accessibility to be considered and checked at an individual document level. HTML documents can also be updated over time, unlike downloaded PDFs.

This makes HTML particularly valuable for reports, guidance, policies and other long-form information that audiences expect to read online. A downloadable PDF can still be provided where it serves a useful purpose, but it does not always need to be the primary way users access that information.

 

The AccessPoint approach 

As with many areas of digital accessibility, context is important when delivering the best possible solution to the end user. Whilst we would typically advise to use HTML content where possible, there are still cases where PDFs provide real value, and circumstances where both can be offered simultaneously.

 

By discussing your exact content requirements with our team at AccessPoint, you can better understand the options available, and begin delivering inclusive, engaging, and accessible content to the users who matter the most to your organisation.