ASPIREpapers 005
The ASPIRE Guide to Accessible PDFs
Part 3: Accessible PDFs in education – create, test, cry…
Alistair McNaught
17 May 2021
If you thought making accessible PDF documents from accessible Word documents was one of the easier accessibility wins, think again.
​
There are no easy wins with PDFs. Even getting the audit tools to agree is a fight. Read on for a blow by blow account…
PDF Accessibility is Challenging
The PDFs on a typical learning platform creates challenges because:
​
1. There are so many of them - some organisations have tens of thousands of PDFs online.
​​
2. Many are from diverse commercial sources (journals, e-books, trade publications) with copyright and IPR restrictions – this restricts the organisation’s right to create blanket accessibility improvements.
​​
3. They are created via a wide range of different tools, from Word exports to Adobe Acrobat to InDesign, Quark Express and so on. Different tools allow different degrees of accessibility.
​​
4. The producers work in widely different contexts:
​​
-
Staff creating teaching notes have limited tools and expertise at their disposal (usually Microsoft Word).
-
A college or university marketing team may have PDF specific skills on Acrobat or InDesign.
-
Commercial suppliers may have wide skills in PDFs, XML, EPUB and other formats.
-
Accessibility awareness and opportunities can vary in each context.
​​
5. Getting basic accessibility into a simple PDF layout is relatively easy but beyond the simplest layouts, 100% accessibility compliance requires specific skill and training.
​​
6. Accessibility test results can be contradictory.
The Nature of the Challenge
The good bit about PDFs is their ability to faithfully reproduce content from a huge range of formats such as word processors, spreadsheets, presentations et cetera. Even when the source document is fully accessible, PDF quirks mean extra work is needed. Even simple things are hard. Accessible hyperlinks in the source file “must be converted to active links and be correctly tagged in the PDF file” (Adobe guidance on creating accessible documents).
​
You need Acrobat Pro DC to create fully accessible documents. Adobe provide detailed guidance on making PDFs accessible. But it is a complex task. WCAG guidance on creating accessible PDFs covers over 29,000 words in 163 pages...and assumes skill in Adobe Acrobat Pro.
A pragmatic approach to PDF accessibility
Guidance that requires people to do the impossible is pointless - in fact, it is counter-productive. It undermines the value of what you are trying to achieve. To move accessibility practices forward, the guidance must be proportionate and achievable.
The example below explores a worked example that could apply to most people creating PDFs for students. It’s not perfect (there’s a forensic analysis at the end) but it is achievable.
STEP 1: Create an accessible Word document
A Word document is created using good accessibility practices. It passes the Word accessibility checker. It reads well with both Windows Narrator and NVDA screen readers.
Figure 1. A screenshot of an accessible Word document with good heading structure, logical table layout, alt text etc.
STEP 2: Export it as a PDF
A PDF is created by exporting from Word and selecting the following options:
​
-
Create bookmarks using Headings.
-
Document structure tags for accessibility.
-
PDF/A compliant.
STEP 3: Check accessibility of the exported PDF using automated checkers
The PDF is run through two different accessibility checkers for PDFs – (i) PAC 3 - a desktop program and (ii) the online PAVE checker. According to these checkers the document has several accessibility problems.
TEST 1: PAC 3
PAC 3 reports 9 failures:
​
-
5 are hyperlinks that are interpreted as “annotations missing alternative descriptions”,
-
1 missing PDF/UA identifier
-
Title missing in document’s XMP data
-
2x “Tab order entry in page with annotations not set to “S”"
TEST 2: PAVE
The PAVE online tool came up with a different, but overlapping set of “failures”:
​
-
It claimed it automatically fixed 20 issues,
-
Title was missing from document properties
-
The 5 hyperlinks in the document were flagged as “Missing link alternate descriptions”.
These findings appear to suggest that either the Word accessibility checker misses accessibility issues (false negatives), or the automated tools give false positives.
STEP 4: Triangulate findings using Adobe online conversion service
Given the apparent accessibility failures generated by the conversion from an accessible Word document, it’s worth trying a different conversion route using Adobe’s own conversion service. Perhaps the route taken to create an accessible document influences the final output?
​
Adobe’s cloud-based service (https://pdf.new) allows users to upload a Word document and then download the converted PDF.
​
​These are the results for the PDF generated from the accessible Word document.
TEST 1: PAC 3
This identified 34 failures in the document – mainly around structural elements and alternate descriptions. When these were explored in more detail it turned out that the reporting included significant double counting – there were actually 13 “errors”:
​
-
5 x "Link" annotation is not nested inside a "Link" structure element.
-
5 x Alternative description missing for an annotation.
-
1 x "Sect" structure element used as root element.
-
1 x PDF/UA identifier missing.
-
1 x "DisplayDocTitle" entry is not set.
TEST 2: PAVE
The online PAVE tool claimed:
​
-
It automatically fixed 24 issues,
-
Title was missing from document properties
-
The 5 hyperlinks in the document were flagged as “Missing link alternate descriptions”.
-
3 of the 5 were flagged as Wrong annotation tag – being tagged with Paragraph instead of link.
STEP 5: Manually testing the document
Given the apparently large range of PDF accessibility failures - in a document that started as an accessible Word document, the two PDF versions were manually tested to see the impact on real users.
Table 1: Testing the PDF exports on Adobe Acrobat Reader
Table 2: Testing the PDF exports on Edge browser.
Table 3: Testing the PDF exports on Chrome browser.
Conclusions
The depressing findings from these tests can be summarised as below:
​
-
A document can pass Microsoft Word’s automated accessibility checker yet, when exported to PDF, fail automated PDF checkers.
-
The tool you choose to read the PDF makes a big difference to the reading experience. The most accessible reading experiences are found using Acrobat Reader. Windows Narrator does not currently work with Acrobat Reader.
-
Different browsers give different reading experiences.
-
Headings added via Word and turned into bookmarks work for sighted users but are not reliably turned into navigable headings a screen reader can use in the PDF.
These findings need to be taken with a degree of caution - a more experienced screen reader user may have used more sophisticated strategies to get to the content. But the fact remains – significant accessibility barriers exist.
​
Creating accessible PDFs is difficult and time consuming. Wherever possible:
​
-
Choose formats that are natively more accessible (or can be easily made so) like EPUB, HTML or Word documents. You don’t have to buy Office to benefit from the accessibility features of a Word document. Most free alternatives will provide similar features like the navigation pane.
-
If you still want to make PDFs available to your users then at least give them a choice – make the original document available as well!
-
If you still need persuading as to best practice, note that Government Digital Services provide advice to use HTML instead of PDF.
Key Takeaways
1. Start off creating as accessible a document as you can using a tool like Word. Be aware of the SCULPT guidance or THRIVES guidance – both are great ways of remembering the key principles.
​​
2. Don’t ditch the source document – offer both to your users.
3. Provide guidance to users – most click on links and take whatever comes up. Use the tables above to create user-focused guidance. You can download the tables in spreadsheet form at the link below.
4. If you need training or support, contact us – whether for staff development or industrial scale format remediation!
​
CONTACT
Alistair McNaught is one of the architects of the ASPIRE service and a long-term accessibility advocate. Learn more about the services of Alistair McNaught Consultancy. Follow Alistair on Twitter: @alistairm
If you would like to commission an ASPIREreview or have any questions or need help in creating your accessibility statement and telling your story, please contact us at aspire@textboxdigital.com.
​
​
​
​
​