The Implementation of PDF/UA and Standardized Access to PDF Content

Presenter:  Karen McCall of Accessibil-IT, Head of Quality Control and Training.  @accessibilit

This is my first post of the CSUN 2015 conference, and the first presentation I attended on Wednesday, March 4 at the #CSUN15 conference.  I have a particular interest in this topic because the latest round of accessibility remediation and content updates my web team and the folks I work with at CSUN are addressing is the vast number of Word and PDF documents posted on the CSUN web site.  I’ve also read a little bit about the PDF/UA ISO standard (thanks @WebAIM list serve!) and am interested in seeing how – or if – this has any impact on the work my colleagues will be doing where “the rubber meets the road.”

Accessibil-IT folks handed out some “accessible IT swag” just before the presentation:  a key-shaped USB stick.  Nice 🙂  They claim it’s the best swag offered at the conference…we’ll just have to see about that!

This session is divided into two parts:  brief powerpoint slide presentation, then a demonstration of an Adobe Acrobat Pro document that is PDF/UA compliant with Jaws screen reader.

Karen has been working with Adobe PDF for about 15 years, and has written books, given training sessions, contributed to the standard and much more during that time.  She’s also a Canadian delegate to the standards committee.  Contributes to both user experience perspective and technical standard.

This is written into the newly published US section 508 refresh:  documents will conform to all Level A and AA success criteria in WCAG 2.0 or ISO14289-1 [PDF/UA-1].

PDF Accessibility 101

1. if a PDF is not tagged, it is not accessible
2. Just because a document HAS tags, doesn’t mean it’s accessible
3. Read out loud text-to-speech tool is NOT A SCREEN READER

What is PDF/UA?

• Initiated by AIIM (association for information and image management and adobe systems in 2004
• Responsible for establishing a set of standards for crating accessible PDF
• A technical standard for software developers
• An implementation strategy for achieving accessibility within a PDF
• designed around the same barrier-free principles behind the methodology of WCAG

Why do we need PDF/UA?

• To achieve a reliability of expectations from one PDF to the next
• PDF/UA success criterion are broken down into three parts:

1. File conformance [ISO 14289-1]; file conformance [ISO 32000-1]
2. Reader conformance
3. Viewer conformance

Having a published standard will make machine-readability much easier for vendors like Google, Microsoft and others (think creation & conversion).  Human QA is still going to be needed, but to a somewhat smaller extent.

Question:  will book publishers be required to adhere to this standard?  Not at this time, but we are notifying publishers that there actually IS a published international standard now.  This is part of the reason why we come and give presentations like this at #CSUN15.

Question:  Does the standard cover forms?  Yes, but there’s a distinction between XFA forms and forms created Adobe Acrobat.

As of today, NVDA is currently the only AA-compliant PDF/UA reader.

What’s Different with PDF/UA?

• It provides developers a framework to build accessibility into their application or output file from the start
• It eliminates perceived “best practices” or “user preference” from organizational document accessibility practices
• It’s based on semantics and established document authoring logic

PDF/UA compliant documents will provide a more consistent user experience, which is important for users

•  Provides a prescriptive PDF interaction model which addresses a broad range of disabilities and facilitates the use of many adaptive technologies.
• Leverages the applicable WCAG principles for the best in general usability.

Question:  Does it allow for reflowable text?  Yes.

Question:  How does it provide for tagging diagrams?  There is an implementation guide published by AIIM that describe how to do this.  I recommend you have a look at the “Matterhorn Protocol,” which provides a checklist that describes how document remediators should do this.  The PAC (PDF Accessibility Checker) does something similar (note:  PAC developer is xYMedia, their web site is in German) .  Neither of these tools eliminate the need for human quality assurance.  A comment from the audience highlighted the usefulness of the PAC for people who are new to PDF remediation.  The PAC tool is not itself accessible with JAWS (the devs know about this and are working on it), but it’s actually a great “in your face” way of showing you mistakes in the document.

Demonstration of a PDF/UA-compliant document showed some of the useful features for end-users.  This included use of keyboard shortcuts for document navigation by headers, images, links, tables and more.