Accessibile PDFs?

A frequent question our community is asked: “How do I make an accessible PDF?”

And, even setting aside the large commercial incentives for certain businesses to make accessible PDFs viable, there is a huge community working towards this goal! I have a huge respect for professionals like Deyan Ginev, codeveloper of LaTeXML and instrumental in the ar5iv project converting arXiv preprints to accessibile HTML.

But that’s just it – why are the most significant projects aiming to make accessible scholarly STEM documents not aiming for an accessible PDF, but instead aiming to help authors create accessible HTML?

I believe it’s because it’s just not possible to create accessible PDFs.

Accessibility is not a trivial concern. But I do my best to help professionals in the mathematical sciences create accessible documents, particularly those affected by DoJ’s April 2027 deadline for public institutions to ensure all web content meets meet WCAG 2.1, Level AA requirements.

For working professionals in the mathematical sciences, it’s not trivial or reasonable to become an expert in accessibility. So how can we ensure we’re doing not meeting our legal obligations, but also ensureing we are serving our readers as best we can?

My advice is to connect with communities and technologies that help you author and disseminate semantic and accessible HTML-format mathematical documents. As a co-creator of PreTeXt.Plus I obviously would suggest trying us out, but more crucially I would emphasize the importance of choosing any solution that targets accessible HTML, and not “accessible PDF”.

While initiatives like the LaTeX Tagged PDF Project attempt to help authors create mathematical PDFs that are as accessible as possible, I’m very concerned that this effort is a non-starter. In addition to the numerous examples of failed screenreader parsing of PDFs with math equations, we must consider the accessibility requirement that content reflows to fit the device viewport, even if the user zooms in to read text at the size they can visually perceive.

How do PDFs meet this standard? Well, in practice, they simply don’t! Below I’ll illustrate a PDF recently published in the open access Bulletin of the AMS, and a zoomed-in (via the most popular web browser Chrome) PDF that fails to meet this standard.

Now, it’s technically possible for readers to spend signficant money on proprietary Adobe software that reflows PDF output. But meanwhile, any HTML file will immediately and trivially meet this simple standard. To illustrate this point, let’s compare the content of the Republican National Convention homepage at a standard zoom setting with a zoomed-in view.

Nothing special has been arranged to ensure the accessibility of the RNC homepage, other than content happened to be authored in HTML rather than print-focused PDF. In a nutshell, this is the issue: PDFs are not written to be accessible content for all audiences. Instead, they are designed for creating print-ready documents for fully sighted readers.

So what can we do to help our readers? The first and easiest step is to assume that all PDF output is inaccessible, and then to look towards solutions that publish HTML instead. While writing HTML is not sufficient to guarantee accessibility (nothing, not even AI, can replace the human responsibility to author useful alt text for graphical information), choosing HTML over PDF is an important first step to serving all readers.