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!