Yes. The PDFs on Your Website Need to Be Accessible
I was recently reading an interesting blog post concerning web accessibility. It seemed insightful and informative, until I came upon a link to “download a PDF …” for more information.
But wait. These PDFs were not accessible.
I shouldn’t have been surprised. This kind of thing happens all the time. As the concept of web accessibility enters the mainstream as a “must-have,” the bigger picture is often getting missed.
The PDF Problem
People are sometimes reluctant to accept that PDF’s are included in the scope of web accessibility requirements. It’s not uncommon for organizations to have hundreds of inaccessible PDFs on a site, or to have multiple links off to inaccessible PDFs. The surface of this challenge has barely begun to be scratched.
It’s true that PDFs can be remediated and made accessible, and WCAG 2.1 provides steps for creating accessible PDFs. Generally speaking, though, the process of making PDFs accessible is time-consuming and cumbersome. In the current accessibility climate, the most efficient approach is a mindset shift away from PDFs as the standard for document saving, and toward a realization that properly structured HTML files are the most accessible document type.
When marketing an event online or promoting a product, a PDF is viewed as the go-to solution for saving a file. Organizations design and link offsite to PDFs that serve as digital posters for downloading and printing.
It’s not uncommon for trifold brochures to be saved as a PDF and posted to a site -- not a good UX and abysmal for accessibility.
PDF’s are also relied upon in organizational governance. Meeting notes or agendas tend to be created as Word docs and then saved as PDFs.Governments, healthcare providers, corporations, educational institutions, and large organizations of every kind, have hundreds if not thousands of PDFs on their site that they are just now realizing need to be remediated for ADA accessibility.
Automation: Not the Answer
Automated remediation tools serve as only a partial solution, at best. For one thing, automated tools cannot be counted on to accurately create alt text for images. That’s a task that will always call for human judgment.
A bigger issue is the fact that content on a WCAG compliant web page is required to be structured within the H1 to H6 HTML hierarchy of headings. Headings on a PDF promotional page or product announcement cannot be counted on to follow any particular logic that either a screen reader or automated remediation tool can make sense of.
PDF Evaluation and Prioritization
An accessibility audit on a site that includes hundreds of PDFs functions akin to triage, with each PDF being evaluated as necessary or not for remaining on the site, followed by a strategic evaluation as to whether it makes more sense to remediate the PDF for WCAG compliance or convert it to an HTML file.
This exercise proves to be strategically valuable for many reasons. I’ve yet to encounter a website that does not benefit from an overall inventory and focus on clearing out the “clutter.”
As is the case with all initiatives designed to ensure WCAG compliance, inventory and auditing of PDFs for accessibility sets the stage for more sustainable web strategies, greater inclusivity, and better UX for all.
There’s much more to learn. Please join me next month for our upcoming training where we will cover the PDF accessibility requirements within the broader scope of WCAG compliance.
Making PDFs Web Accessible
Wednesday, March 18, 12 p.m. - 1 p.m. CST