WCAG 2.0 and PDF/UA – Your Questions Answered

Home / WCAG 2.0 and PDF/UA – Your Questions Answered
windows-7-key-kaufen windows-7-key-kaufen-64-bit-key Windows-7-Ultimate-Key-Kaufen windows-7-professional-key-kaufen windows-7-key-kaufen-online Windows-7-Home-Premium-64Bit-OEM-key windows-7-home-premium-key-online-kaufen windows-8.1-keys-kaufen Windows-8-guenstig-kaufen-key windows-7-enterprise-key-kaufen windows-7-enterprise-64-bit-key windows-8-1-enterprise-key Windows-8-1-Enterprise-key-online Windows-8-1-Pro-Key-Kaufen windows-8-key-kaufen

[[include:_PageDate name=WCAG-20-and-PDF-UA-Your-Questions-Answered]]  Return to Logical Structures

PDF document icon with WCAG 2.0 Level AA seal.I’m getting more and more questions about PDF/UA. Wondering when it would finally emerge, one well-known accessibility expert has already located PDF/UA somewhere between world peace and dark chocolate KitKat. Accordingly, it seemed like a good time to starting answering some of these questions before someone mistakes PDF/UA for a missing chapter in the Book of Revelation.

Question 1: How does PDF/UA fit with WCAG 2.0?

In principle, WCAG 2.0 offers “one stop shopping” for accessibility in web content. Its guidelines cover visual, audio, mobility and cognitive impairments in a more-or-less technically neutral manner. Many government agencies have already adopted or are considering adoption of WCAG 2.0 to govern accessibility in their web content. A few are taking WCAG 2.0 beyond its own design parameters in an attempt to address ALL electronic content – and maybe applications as well. That subject’s for another day.

As written, the target audience for the Web Content Accessibility Guidelines is, not surprisingly, web content (HTML) producers, content authors and policy-makers. While requiring certain functional attributes be available (for example, in multimedia players), in many cases WCAG 2.0 is neither designed to be nor especially usable as a technical standard for binary file formats that aren’t fundamentally of the web.

Traditional technology standards focus on interoperability – features that allow parts, components or interfaces from one manufacturer to work with those from another. Interoperability allows electrical devices to share the same power supply through standardized power plugs and sockets. It’s interoperability that allows Adobe’s PDF Reader to open and display PDF files produced by Foxit’s PDF software, and makes it possible (via MSAA) for assistive technology to access MS Word and other applications and content.

Ensuring interoperability in electrical equipment (or toilet seats) is one thing – there are only so many variables. Things fit and function, or they don’t. In software, especially something as internally sophisticated as PDF, resolving ambiguities generally requires precise statements about low-level technical specifications. In most cases WCAG 2.0 success criteria and techniques focus on web content, specifically, HTML/CSS and JavaScript. For non-web technologies, some Techniques provide a degree of interpretation and implementation advice, but developers are generally left to sort it out for themselves. Besides, the Techniques, the WG reminds us, are NON-normative. They can and do change; indeed, developers need not use the “official” techniques at all.

Screenshot showing the only appearance of "PDF" in WCAG's normative text: "Example: Some common examples of Web content technologies include HTML, CSS, SVG, PNG, PDF, Flash and JavaScript.

The only (normative) mention of PDF in WCAG 2.0

In any case, as has already been said: WCAG 2.0 is for web content. While PDF files are often found on websites that’s probably not quite the same thing. Certainly, it’s hard to see PDF as web content in the classical sense. Even WCAG’s normative text only mentions PDF once, and in as casual a way as possible, sandwiched between PNG and Flash (PNG? Really?).

Accessible PDF wasn’t impossible before PDF/UA (or WCAG 2.0 for that matter). I’ve delivered accessible PDFs since 2001. Without PDF/UA, though, I’ve had no way to prove anything outside of specifications I’d written myself. There was no agreed set of technical norms for assessing PDF accessibility in its own right. WCAG 2.0 by itself hasn’t changed that fact.

Without PDF/UA, attempts to conform with WCAG 2.0 in PDF might result in similar outcomes in many cases, but without a shared set of technical norms true interoperability remains a guessing-game. Big-picture, that’s not going to fly, economically and otherwise.

Complex non-web technologies require technically specific standards such as PDF/UA if WCAG 2.0 principles and guidelines are to be manifested in files that any vendor can recognize and respect within their own implementations.

Is that too technical?

Let me make this really simple…

If I’m responsible for a given PDF document’s conformance with WCAG 2.0, I need to know when someone else’s software will agree that I’ve done my job.

If your software disagrees with my software we’ve both got problems. Maybe we are both right, maybe we’re both wrong. Either way we are grinding gears rather than getting on with business.

That’s why we need PDF/UA.

PDF/UA provides technical specifications for WCAG 2.0 conformance in PDF content

PDF/UA is needed because while the PDF specification creates accessibility mechanisms it fails to set clear rules for actually creating (or delivering) reliably accessible PDF content. PDF/UA focuses exclusively on providing low-level technical specifications of sufficient detail to illuminate the practical realities of accessibility in PDF, including implementing WCAG 2.0 in the PDF context.

While PDF/UA is not a complete answer to WCAG 2.0 conformance in PDF it will suffice in the vast majority of cases. If they’re sensitive to accessibility at all, developers and authors who include movies or audio, funky JavaScript or some other unusual cases already know that they might run afoul of WCAG 2.0 with or without PDF/UA.

Question 2: Can my PDFs conform to WCAG 2.0 without PDF/UA?

This is a trick question, but the answer’s still worth knowing.

First of all – YES – there’s no question that it’s technically ‘possible’ to conform to WCAG 2.0 in PDF without conforming to PDF/UA. Let’s go further: it’s possible to conform to WCAG 2.0 with a PDF file that’s not even tagged. Granted, a PDF would have to be extremely simple to squeak past WCAG 2.0 requirements without tags, but it is ‘possible’ (if the stars content streams happened to align correctly).

Far more interesting is this question: can a PDF violate PDF/UA in any substantive way and still conform to WCAG 2.0? The answer: NO. What does that mean? If you are serious about WCAG 2.0 conformance in PDF files, you should be thinking about PDF/UA.

WCAG 2.0 does not require adherence to any technology-specific accessibility standards, PDF/UA or otherwise. WCAG 2.0 includes Techniques for a variety of technologies, but WCAG’s Techniques, as the WG makes clear in its discussion of conformance, are not the basis for measuring conformance with WCAG 2.0’s normative text. As many have noted, the PDF-specific Techniques, while useful, do not presently represent a complete set encompassing all technical requirements for accessibility in all PDF documents.

PDF/UA provides a normative and comprehensive means of testing PDF content for conformance with WCAG 2.0. Fail PDF/UA in any substantive way, and your file won’t comply with WCAG 2.0.

As I’ve said before, WCAG 2.0 is far, far broader than PDF; conforming with PDF/UA does not assure conformance with WCAG 2.0. AIIM’s document “Achieving WCAG 2.0 with PDF/UA“, to be released shortly after PDF/UA becomes available to the public, will make clear which WCAG 2.0 Success Criteria PDF/UA fulfills and which it does not.

I’ll answer another pair of questions in a later installment! Or perhaps you have a question? Add a comment to let me know, or feel free to get in touch.

Return to Logical Structures