ASPIRE papers

The ASPIRE papers logo.

ASPIREpapers 005

The ASPIRE Guide to Accessible PDFs
Part 3: Accessible PDFs in education – create, test, cry…
Alistair McNaught
17 May 2021

An illustration of a document page and a pencil, representing creating content.
An icon of a test tube and chemical flask, representing the testing phase.
An icon of a pear with a sad face, crying.

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

An icon of the Word document logo.
A left to right arrow connecting the Word document to the PDF and representing conversion to PDF.
An icon of the PDF logo.

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.

An icon of the PDF logo.
An icon of a checklist on a clipboard, representing the guidelines for creating accessible PDFs.

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.

Screenshot shows navigation pane on left, parish council agenda in middle and results of Word Accessibility checker on the right.

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

An icon of the Word document logo.
A left to right arrow connecting the Word document to the PDF and representing conversion to PDF.
An icon of the PDF logo.

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.

An icon of some scientific lab equipment represents the testing phase.
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

An icon of a clipboard containing a report and graph, representing the conclusion section.

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

A takeaway bag and 2 take out coffees, representing the key takeaways from this article.

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.

End of page icon.