You can criticise Apple for many things, but one of its saving graces has been its sustained championing of accessibility. This isn’t a particularly large or lucrative market, but a very important one: you may not have any accessibility needs today, but as you grow older you almost certainly will.

Efforts to incorporate features for accessible PDF documents started in earnest fifteen years ago, in PDF/UA, for Universal Accessibility, and are now embodied in ISO 14289, which lays down the variations and features required to make a PDF document fully accessible.

Key requirements for a document to comply with PDF/UA include:

• text must be meaningfully tagged and flowed into a reading order,
• meaningful (as opposed to decorative) graphics must have alternative text descriptions,
• content which cannot be read as plain text, such as that dependent on JavaScript or colour, is prohibited,
• fonts must be embedded, with text mapped to Unicode (a beneficial side-effect).

This article looks at how some popular Mac PDF apps already support the key accessibility feature of reading a non-compliant PDF document, and how you can prepare an existing PDF on a Mac to be compliant with PDF/UA. My example file is one of the PDF help files for one of my apps, created using Nisus Writer Pro, which generates clean and well-structured PDF, far better than many other page layout apps, for example.

All the apps that I tested (Preview, PDFPenPro 11, Adobe Acrobat Reader and Pro, and Podofyllin) supported some form of speaking a PDF document, except for PDF Expert, which surprisingly lacks this feature. However, implementation of this basic feature isn’t so even: in Preview, you have to select the text that you want read aloud, and Adobe Acrobat doesn’t put the menu command in the standard location, but in its View menu, where it has to be enabled before use, which seems odd.

The biggest problem with all the apps that can read PDFs is, inevitably, that they read the PDF in the order it is given on the page. My example has header and footer text, and some embedded navigation links, and those were read out as they were encountered. This is exactly what tags and flowing into reading order are intended to address.

Despite the ISO standard for PDF/UA being published almost exactly seven years ago, its support by much of the PDF industry including Adobe, and support from the US Access Board in federal policy on accessibility (‘Section 508’), very few products on any platform provide good support for making an existing document comply with the PDF/UA standard.

Even tagging and flowing text is a feature which seems to be confined to the likes of Adobe Acrobat Pro, and more specialist tools. Disappointingly, neither PDF Expert nor PDFPenPro 11 appear able to perform this fairly fundamental task. Adobe Acrobat Pro version 19 puts all these tools in its Accessibility toolkit. Unfortunately, they are so riddled with bugs as to be almost unusable, at least in the current macOS version.

I started by letting Acrobat autotag the document, to see what sense it made of this relatively clean and well-ordered PDF. That was a mistake because it failed to recognise the regular headers and footers, and merged other contents into single tag units. I therefore tried removing its tags from one page at a time and correcting the tagging and reading order by hand.

This proved even more disastrous, as the tagging controls had a mind of their own. When I tried to make the headers and footers into artifacts, for example, it decided that they would be body text instead. After an hour of frustrated attempts to mark the whole document up in a meaningful reading order, I abandoned the job as simply impossible given the current state of the tools.

Assigning alternate text to the three screenshots included in the help document was much easier using the Set Alternate Text tool, or so I thought. However, when I ran a full check on the document, it failed because those three figures apparently still lacked alternate text. Even that had failed to work properly.

After several hours trying to turn my simple eight-page PDF into a document which was compliant with PDF/UA, I also discovered that there is no way to save it as a PDF/UA document as such. So I just have it on trust that the modified file is compliant, if you overlook the tests which it should pass but still seems to fail.

The final twist in this is that PDF/UA compliance also has limited effect on the accessibility of the document: the only two apps which paid the slightest attention to all my work providing alternate text, and tagging and flowing text content, were Adobe Acrobat Reader and Pro. Preview, PDFPenPro 11, and my own Podofyllin are all blissfully unaware of PDF features to support accessibility because they aren’t built into PDFKit and the Quartz 2D PDF engine in macOS.

Now if only someone like Tim Cook and his accessibility evangelists at Apple got their teeth into this little pit of inaccessibility.