Part 1 of: why a standards-compliant PDF is not necessarily the same thing as an accessible PDF
PDF/UA is the ISO standard for PDF accessibility. If all PDF authors worked to it, the quality of PDFs across the board would rise dramatically.
However, it is important to understand that a PDF/UA-compliant document does not necessarily equate to a fully accessible PDF. Sometimes it will be necessary for document authors to go considerably further than simple standards compliance in order to ensure that a PDF is accessible to all assistive technology (AT) users. Here, and in a series of forthcoming posts, we will provide examples of how and why this is so.
In this post we will look at the importance of setting a PDF’s tags’ reading order, which is required under PDF/UA, as well as its non-tags’ reading order (explained further below) which is not required for PDF/UA compliance.
PDF/UA and reading order
PDF/UA 1.0 specifies that a PDF’s reading order (or ‘logical order’) should be set in the document’s tags (or ‘structure tree’). Specifically, it states:
7.1 General …Content shall be marked in the structure tree with semantically appropriate tags in a logical reading order…
This is fine for most ATs such as JAWS, SuperNova or NVDA that take their reading order from a PDF’s tags. However, some, such as the popular literacy software Read&Write Gold, do not. For them, a PDF’s reading order must also be set correctly in Acrobat’s Order Panel and/or Content Panel (the non-tags’ reading order).
Correcting a PDF’s reading order for all AT users
In the first example, the PDF’s tags are arranged in a coherent order, and JAWS reads the content as you would expect it to. However, when we then run Read&Write Gold/PDF Aloud on exactly the same document, the reading order is all over the place.
Video: PDF accessibility and the non-tags’ reading order
At least 10% of your target audience
So how large a proportion of your target audience will be affected if you neglect to correctly set a PDF’s non-tags’ reading order?
Read&Write Gold is one of a number of ATs classified as ‘literacy software solutions’ (sometimes also known as ‘reading solutions’). The GOV.UK assistive technology users’ survey 2016 found that 15% of its respondents were literacy software solutions users. Of these, over 68% were Read&Write Gold users, hence accounting for more than 10% of the total.
Furthermore, there is good reason to believe (but no publishable stats, sadly) that in some sectors (education in particular), usage of Read&Write Gold is considerably higher than 10% of all AT users. And, as stated previously, it is not the only AT that works in this way.
Reflow (and WCAG 2.1)
And finally, when you reflow a PDF (Ctrl/Cmd + 4) the content’s reading order is also determined by the non-tags’ reading order. Those following developments with WCAG 2.1 will no doubt be aware that the ability to reflow text properly is due to become a Level AA success criterion (as of this writing, Working Draft 7, SC 1.4.10). Those requiring correctly reflowed text are clearly another section of your readership whose needs should be catered for. In a PDF, this means getting both reading orders right.
Fixing a PDF’s non-tags reading order is not a PDF/UA requirement. However, doing so is important in order to ensure the accessibility of a PDF, at least until such a time as all the major ATs (and a PDF’s reflow view) take their reading order from tags.
Try it yourself
The above examples were, of course, created specifically for this demonstration. If you would like to try out a real-world example, we provide here (with permission) a client’s PDF as an example of best practice. The infographics on pages 4 and 5 are particularly good examples of the importance of getting a PDF’s non-tags reading order right.
Afterword: when PDF is more accessible than HTML
Lastly, in the video, you may have spotted the bar chart offering two completely different renderings to different ATs (JAWS and Read&Write Gold). If you know how to author a PDF properly this is easy to do. However, you will struggle to replicate this in an HTML page. We will return in more detail in a future post to the theme: “when PDF is a more accessible format than HTML”.