Converting PDFs into accessible formats

For years, PDF (portable document format) files have been a get out of jail card for web content editors, allowing us to provide pages and pages of additional information for residents without cluttering up web content.

All good things must come to an end though and the inception of the Web Content Accessibility Guidelines (WCAG) has made PDFs the bane of our lives.

With more than 3,000 PDFs sitting on our website, we felt (and still do) like we were climbing Mount Everest when we began the arduous process of making these document types accessible.

Aside from improving the accessibility and compatibility with screen readers, this process has also enabled us to review a lot of content that was perhaps flying under our radar. We use SiteImprove as an automated auditing tool that will flag broken web links that in HTML, but it won't detect broken URLs within a pdf. As a result, we've also been able to bring some of our content up to date, providing more reliable information to our residents. 

We started with some quick wins, which involved linking to the original source of the document (e.g. DEFRA or The Cabinet Office websites) rather than hosting these documents as downloads from our website. We also started converting pdf material into HTML by creating new webpages. This was an ideal solution for documents that were less than 10 pages, as the newly created page didn't require the user to do too much scrolling.

However, the biggest issue has arisen with more lengthy documents, such as The Local Plan, which is 389 pages long. These are simply too long to have sat on a webpage, so that leaves us with the alternative of formatting the document correctly to ensure that it is compatible with assistive technologies. 

This is a very big job – but learning how to do it in the first place was half the battle. Watching how-to videos on YouTube was supplemented by guidance from GDS (Government Digital Service) and Kent Connects (Kent County Council working in partnership with University of Kent).

Both Word and Acrobat Pro have accessibility checkers installed on them that will run automated tests on your document and tell you what the accessibility issues are. Some of these are quite straight forward and easy to fix, whilst others require manual, human checks on top.

Adding heading styles and checking the wording of hyperlinks as fairly straightforward enough, but checking the reading order of tables had us scratching our heads a bit more.

We haven't yet completed our climb and are still working tirelessly to remove this old-fashioned digital document type from our website. It's slow progress at times but, when finished, we'll be rewarded with a slicker and more accessible website.