PDF Association logo.

Facebook
Twitter
YOUTUBE
LINKEDIN
XING
About the contributor
PDF Association

Mission Statement: To promote Open Standards-based electronic document implementations using PDF technology through education, expertise and shared experience for stakeholders worldwide.
More contributions
Participating in the PDF Techniques Accessibility Summit

The PDF Techniques Accessibility Summit’s objective is to establish a broad-based understanding of how PDF files should be tagged for accessibilty. It’s an opportunity to focus on establishing a common set of examples of accessible PDF content, and identify best-practice when tagging difficult cases.

Modernizing PDF Techniques for Accessibility

The PDF Techniques Accessibility Summit will identify best-practices in tagging various cases in PDF documents. Questions to be addressed will likely include: the legal ways to tag a nested list, the correct way to caption multiple images, the appropriate way to organize content within headings.

Refried PDF

My hospital emailed me a medical records release form as a PDF. They told me to print it, fill it, sign it, scan it and return it to the medical records department, in that order. In 2018? To get the form via email (i.e., electronically), yet be asked to print it? Did the last 20 years just… not mean anything! So I thought I’d be clever. I’d fill it first, THEN print it. Or better yet, never print it, but sign it anyhow, and return it along with a note making the case for improving their workflow. The story continues…

Slides and video recordings of PDF Days Europe 2018

You missed the PDF Days Europe 2018? Never mind! Here you can find the slides and video recordings of all 32 stunning sessions!

Using PDF/UA in accessibility checklists

PDF/UA, like PDF itself, is internally complex, but used correctly, actually makes things easier.

PDF/UA Validation: The Matterhorn Protocol

A project of the PDF Association’s PDF/UA Competence Center since May, 2012, the Matterhorn Protocol details an algorithm to determine how a given PDF file fails to conform with PDF/UA, and a means of reliably sharing this information. The PDF Association’s PDF/UA Competence Center plans to release this document in Q1, 2013.

Why we need the Matterhorn Protocol

Accessibility is not a conceptually or technically trivial feature. Those responsible for producing accessible content are committing to consistent authoring techniques, providing alternative text for graphics, ensuring correct structure in tables, checking for the acceptable use of color, and so on.

Validating PDF accessibility features for complete, high-quality usage involves some level of human judgement and is therefore expensive. As such, it’s important that various good-faith validation efforts use a similar basis for assessment. To maximize cost-effectiveness, ideally, such assessments would persist for reference by downstream users.

Without a fully interchangeable model for validating accessibility metadata no cost-effective guarantee of accessibility is possible because the results of a meaningful audit, validation or corrective process cannot be efficiently or reliably shared.

How is the Matterhorn Protocol structured?

The Matterhorn Protocol is implemented using RELAX NG (ISO/IEC 19757-2:2008); said XML to be embedded in the output validated PDF.

Each report should be a distinct iteration. The rules of the road will prohibit implementations from modifying reports written by other implementations or created by other agents; however, removal of complete reports will be permitted.

The core of the Matterhorn Protocol is a table describing PDF/UA Validation Metadata Checkpoints. This table presents the “shall” statements from the file specifications section of PDF/UA, identifying failure conditions for each.

In addition to specifying terms for validation and a means of recording validation results, the Matterhorn Protocol also identifies whether specific tests may be validated by machine or human based on realistic best-practice approaches at the present time. Some checkpoints may always be decided by machine, some usually or probably require human interaction.

What’s not covered

Of course, there are limitations. Worthy of note is the fact that pathological software behavior (such as “flickering” by using a script to cause animation effects via a series of actions) is not addressed.

Perhaps more significantly, the concept of “partial conformance” and the significance of non-conformance are intentionally not addressed in this document. At this point the PDF/UA Competence Center feels that these questions should be up to the implementer.

Come to the next meeting!

The PDF Association’s PDF/UA Competence Center holds its next meeting on January 31 at 1100 ET / 1700 CET at which time we’ll be attempting to complete specifications for the publication of the Matterhorn Protocol. We encourage all interested members of the PDF Association to attend!


Tags: Matterhorn Protocol, Validation
Categories: PDF/UA