PDF Accessibility: What’s in Store?

Post was first published on Media Access Australia’s AccessIQ

There’s been a lot of talk lately, in technology circles, about what’s in store for PDFs. For organisations that are looking for ways to ensure on-demand accessibility for high volumes of PDFs created at the enterprise IT infrastructure level—this is a particularly relevant question.

With that in mind, I wanted to address it here, and offer my own two cents on what I think is going to happen with PDFs—and, specifically, accessible PDFs.

The end of the PDF?

The debate comes down to this: is the PDF being replaced by HTML and XML formats? Many feel that it should be, arguing that HTML and XML simply offer a better user experience, and are easier to make accessible, with a tagged structure inherently compatible to screen reader technology for the blind. From my perspective, though, PDFs aren’t going anywhere—for several different reasons.

First of all, Adobe has invested a lot at the code level for creating better PDFs, including the PDF/UA format, a universally accessible PDF format meant to help PDFs more easily meet accessibility standards and requirements.

And companies, as well, have invested heavily in PDF technology, because most organisations still utilise PDFs—in fact, it’s still the de facto standard for communicating information in a format that’s viewable to most readers.

A trusted technology

Even for those companies who may be using HTML for some uses, there still exists a need for PDFs. Take a bank, for instance. Banks regularly offer their banking information in rich HTML on their online portals, for an informative, user-friendly experience. Most customers wouldn’t think of searching out a PDF in lieu of that experience—at least not for their everyday banking.

Most financial institutions have invested heavily in creating an IT architecture that allows massive amounts of data to be funneled through different types of processes and applications to be converted to both a print file—that goes to the printer and results in the paper statement some still receive via snail mail—and a PDF file, the de facto standard for online presentment.

But banks also have a legal obligation, as do other industries: they must meet regulatory compliance standards that often require the PDF format they output be the official record on file. So even if that bank is offering statement summary information through HTML, they still have an archive of PDF records.

And when individual clients need documentation, for instance, to prove creditworthiness for a mortgage or a loan, HTML won’t cut it—they need the official PDF documentation for those purposes as well.

Accessible answers

From an accessibility standpoint, HTML does have the advantage that covers all scenarios. Tag structure is inherent to HTML, so accessibility can be built in during design. PDFs, on the other hand, often need the tags added, since many are simply output as image-only PDFs.

But technology is  now available  that can  automate the accessibility of these PDFs, making communications created in high volumes at the enterprise IT level, like bank statements, medical notices, bills, etc. completely accessible on-demand, at the same time for all customers—with and without disabilities.

And that’s important. Having full, independent access to information, especially critical financial and health information and documentation, is something no one should have to wait for since technology is available to make it happen. Because even with the growing use of HTML, I don’t think PDFs are going anywhere.

If you have any questions, please leave them in the comment section below or contact me at skelly@actuate.com

Accessible PDF: Enterprise Vs. Desktop Accessibility Requirements

First published on G3ict.org.

We receive a lot of questions at Actuate about our PDF Accessibility Appliance, a solution designed to make PDF customer communications accessible to the blind and visually impaired community. Many of the customers who approach us want to know how our solution differs from others on the market and what types of documents are best suited for our solution. Actuate’s Accessibility Appliance is unlike other accessibility products as it is designed for PDFs created at the enterprise level. So what’s the difference between PDFs created at the desktop level versus the enterprise level? It’s a good question that I’m going to delve into here.

The Desktop Level

PDFs created at the desktop level are done so by a person, generally using popular programs such as Microsoft Office, Adobe Creative Suite, etc. That’s what defines this level of PDF creation: individual people create the individual document. An example could be as simple as a newsletter created for delivery or web distribution to all customers, or may be as complicated as the thousands of program documents generated each year by Medicare/Medicaid insurance providers and found on their websites. Because Medicare is a federal program, there is a lot of documentation involved that needs to be changed annually as the legislation itself changes – even though there may be hundreds of thousands of documents, though, they’re all still unique and need to be created one at a time by a combination of individuals.

The Enterprise Level

PDFs created at the enterprise level are generally personalized customer communications automatically generated by an application, typically within the IT department – each one is not individually created by a person. These types of documents include credit card and bank statements, telecommunications billing, tax notices, medical explanation of benefits, etc. What defines all of these is that there may be millions of personalized individual documents, but they’re all created from a single template. So while each document contains individual personal data, they all look very similar in structure, and it’s not a single person – or even a group of people – who inserts that data. Rather, it’s done automatically, using a document composition engine. A template is generally created one at a time by an individual or group of individuals, then the engine automatically pushes the data through that template to put out these documents at the scale and speed that’s required.

Accessibility Options

When it comes to considering accessibility for documents, PDFs created at the desktop level will generally need to be tagged manually. This is the traditional path to accessibility and currently there isn’t technology available that addresses automation of these ad hoc documents in scale and with reliability – meaning not needing manual re-touch of the tag structure. For those created at the enterprise level, though, automated solutions like the Actuate Document Accessibility Appliance exist that do just that – automating the remediation of high volumes of PDFs able to meet WCAG 2.0 Level AA and Section 508 standards without the need for manual tagging or tag re-touch. The Actuate Document Accessibility Appliance is designed for high-volumes of documents created by a document composition engine at the enterprise level and output as PDF. The Accessibility Appliance allows for the creation of highly intelligent templates, again at the enterprise level, building in the accessibility rules for tagging that will get incorporated into the PDF post creation, i.e. automated remediation. This can happen in batch or in real time on demand, making them accessible to visually impaired customers and the screen reader technology they use to access, navigate, and fully consume digital documents.

In the case for these high volume generated documents, manual tagging is all but impossible. There are often millions, hundreds of millions or more of individual documents to consider, so the only way to manage accessibility without an automated solution is through an exception process. This process would require visually impaired customers to self-identify as disabled and deal with delayed delivery times while their document is remediated manually. The exception process often doesn’t scale either due to the sheer volume, and forces companies to hire and train full time internal resources or hire expert vendors, often costing $5 to $35 per document page. The Actuate Document Accessibility Appliance helps get around that – allowing for all customers, with and without disabilities, to have access to fully accessible documents on demand, especially medical and financial communications equally at the same time.

If you still have any further questions, please leave them in the comments section below, or contact me at skelly@actuate.com .