This repo contains the PDF Association's Techniques for Accessible PDF as published on pdfa.org. The contents of this repo are intended primarily for developers, whereas the same content is presented in a friendlier manner on pdfa.org. Developers and end-users alike can post Issues in this repo as public comments on the Techniques. These will be reviewed by the PDF Association's Accessibility Liaison Working Group.
Get your zero-cost copy of ISO 14289-1, ISO 14289-2, & ISO:TS 32005 now!
This repository contains a tree of technique folders.
Each technique is identified by a technique-info.yaml file in a directory.
That directory contains four files that define the technique:
technique-info.yaml- A file containing all data fields for the technique, except for the Description and Tests, which are in separate files listed below.
README.md- A GitHub markdown file containing the description of the example file and the accessibility technique.
tests.md- A file containing a list of tests to check whether or not a particular PDF meets the requirements of the technique.
<title>.pdf- The PDF example file for the technique.
Data fields for technique-info.yaml are specified in the /config/
directory of this repository. Most fields are fully specified in
/config/fields.yaml.
Most data fields only allow certain values from a predefined list. Those are
either specified in fields.yaml or in another .yaml in the /config/
directory. The description: entry for a given field will indicate what, if
any, other file to consult for that field.
There are several "Checked" fields listed in fields.yaml that are of
type: Timestamp, such as "LWG Tool Checked". Each of these fields records the time
when the relevant validator or checker software yielded "expected results" for the
example PDF file for the technique.
"Expected results" means:
- A PASS example passes validation, unless the validator is in error.
- A FAIL example passes all checks unrelated to the failure that the example demonstrates, unless the validator is in error.
These "Checked" fields are timestamps, as opposed to true/false for example, for two reasons:
- If the sample PDF is updated, the timestamp helps indicate which checks need to be rerun.
- If a different version of the same checker yields different results in the future, the timestamp records when the old version of the checker yielded expected results.