09 — Validation (`PRINT-VALID`)

Status: NORMATIVE. Section owner: audit/pipeline engineering. Related: Issue #2852. References rule IDs across §01–§08.

Scope decision (locked). This section describes an internal print-safe guardrail and reference, not a sellable print-compliance certification. The validation apparatus below is scoped to what our pipelines, audit/ACR tooling, and tag-tree editor can enforce internally, and it is deliberately honest about where automation stops. We do not build a customer-facing certification validation product here; several of the most important print requirements (hand-fill usability, real-lighting glare, comprehension) are structurally out of reach for any automated tool and are called out as such.

Every rule in this section is an our-implementation rule — engineering process, not external mandate.

PRINT-VALID-001 — Bucket taxonomy: automatable / assistable / human-only

Level: SHOULD Applies to: all documents Source: our-implementation rule (framework) Source strength: industry practice Machine-checkable: no (this rule defines the classification; it is not itself measured) Validation: Governance check — every requirement in §01–§08 SHOULD carry exactly one bucket assignment, reviewed when the rule changes.

Every print requirement in this KB SHOULD be assigned to exactly one of three validation buckets, and the assignment SHOULD be recorded so tooling and reviewers know what is expected of each:

Automatable — a deterministic program can decide pass/fail from the PDF object model or rendered raster with no human judgment. Two independent implementations, given the precise method in PRINT-VALID-002, would agree. Examples: body point size, widget geometry, declared page size, print-scale integrity.
Assistable — a program cannot decide the requirement, but it can reliably surface candidates and narrow a human’s search, then a person judges. Examples: caption equivalence to alt text, whether a table’s visual headers are truly obvious, whether a required-field cue is redundant enough. Governed by PRINT-VALID-003.
Human-only — no useful automated signal exists; the requirement is about physical/perceptual/cognitive reality. Examples: hand-fill usability, glare under real lighting, comprehension. Ideally tested by a person with the relevant disability. Governed by PRINT-VALID-004, with a physical procedure in PRINT-VALID-005.

Honest boundary. Most digital-layer checks are automatable; most print-physical and cognitive checks are not. A file can pass every automatable check and still fail on paper. Bucket assignment prevents us from overstating what a green audit means.

Rationale: Without an explicit taxonomy, an automated “pass” gets read as “print-accessible,” which is false for the assistable and human-only majority of print requirements. The buckets set honest expectations and tell each tool what it owns.

Implementation notes: The bucket lives alongside each rule’s machine_checkable field in rules.json (yes→automatable, partial→assistable, no→human-only). The audit/ACR tooling reports per-bucket coverage so a report can say “N automatable checks passed; M assistable checks flagged for review; K human-only checks not evaluated by tooling.”

PRINT-VALID-002 — Automatable measurement methods & units

Level: SHOULD Applies to: all documents Source: our-implementation rule Source strength: industry practice Machine-checkable: yes Validation: This rule is the validation spec for the automatable bucket. Conformance means each method below is implemented such that two independent implementations agree within the stated tolerance.

For every automatable requirement in the KB, the measurement method and units SHOULD be specified precisely enough that two independent implementations agree. The canonical methods:

Point size (PRINT-TYPO-001/002/003, PRINT-LEGAL-014/015/016). Effective glyph size = text-run font size from the content stream Tf operator, multiplied by the vertical scale of the current text+CTM matrix, expressed in PDF points (1/72 inch). Report the rendered size after all matrices, not the nominal Tf operand. Tolerance ±0.1 pt. Where a legal minimum is stated in points (e.g. Drug Facts, ABN), compare against that literal value; where stated in x-height or a named size, resolve to points via the embedded font’s metrics.
Field / widget geometry (PRINT-FORM-001/002/005/006, PRINT-FORM-023). Fill-space and control dimensions = the widget annotation /Rect [llx lly urx ury] in default user-space units (points); width = urx−llx, height = ury−lly, transformed by any page /UserUnit and rotation. Convert to inches (÷72) or millimetres (×25.4/72) for the rule’s stated unit. Tolerance ±0.5 pt.
Contrast (PRINT-COLOR-002). Two values are reported and must not be conflated: (a) screen sRGB WCAG ratio for the digital regime (relative-luminance ratio, 1.0–21.0); (b) print reflectance estimate — as a coarse first-order proxy, treat WCAG relative luminance (sRGB, D65, 0.0–1.0) as a Light-Reflectance-Value estimate (LRV ≈ luminance × 100) and report the reflectance contrast as the LRV-point difference |LRV_text − LRV_bg| alongside the (B1−B2)/B1 × 100 percentage form from PRINT-COLOR-002. This proxy is defensible mainly for near-neutral tones on white stock and is not authoritative for saturated colours or non-white paper (PRINT-COLOR-001/PRINT-COLOR-005). Two implementations MUST agree within ±3 LRV points on the estimate itself — that bounds implementation drift, not real-world reflectance error. Never present the screen sRGB ratio as a paper-contrast guarantee (PRINT-COLOR-001).
Margins & text-block position (PRINT-LAYOUT-012, PRINT-SUBSTRATE-005). Distance from /MediaBox (or /CropBox if present) edges to the bounding box of the marked-content text, in points→inches/mm. Tolerance ±1 pt.
Measure / line length (PRINT-TYPO-010). Characters per line = width of the text column in points ÷ average advance width of the font at its point size, reported as an integer character count (target band, not a single value). Alternatively count glyphs on representative full lines from the content stream. Tolerance ±2 characters.
Page-size declaration (PRINT-SUBSTRATE-007, PRINT-SUBSTRATE-008). /MediaBox dimensions in points → inches/mm; classify against Letter (612×792 pt) / A4 (595.28×841.89 pt) with a ±3 pt tolerance. Print-scale integrity (PRINT-SUBSTRATE-008) is inferred by checking that declared page size matches the intended physical size and that no /UserUnit scaling or fit-to-page hint would shrink content; the actual 100% print is confirmed physically in PRINT-VALID-005.
Leading (PRINT-TYPO-009). Line leading = TL operator value or measured baseline-to-baseline distance in points; report as a ratio leading÷point-size. Tolerance ±0.05.

Rationale: “12pt minimum” is meaningless without saying which 12pt — nominal Tf, post-CTM, or post-/UserUnit. Ambiguous methods let two audits disagree and let scaled-down output pass. Pinning method + units + tolerance makes the automatable bucket reproducible.

Implementation notes: All of the above are extractable with our existing deterministic stack: pikepdf for the object model (/Rect, /MediaBox, /UserUnit, AcroForm, content-stream operators) and veraPDF for structure/tagging. Point-size and measure require walking the content stream with matrix accumulation — this already exists in the flyer-tagger walk_elements path. Register each method as a distinct audit check keyed to its rule ID so the ACR can cite the measured value.

Automatable rule IDs catalogued here: PRINT-TYPO-001, PRINT-TYPO-002, PRINT-TYPO-003, PRINT-TYPO-009, PRINT-TYPO-010; PRINT-COLOR-002 (screen ratio automatable, reflectance estimate partial), PRINT-COLOR-003 (equiluminant-collapse deterministic; reflectance-contrast portion partial via COLOR-002); PRINT-LAYOUT-005, PRINT-LAYOUT-007, PRINT-LAYOUT-009 (automatable by structure/‘presence’, no numeric threshold), PRINT-LAYOUT-012; PRINT-FORM-001, PRINT-FORM-002, PRINT-FORM-005, PRINT-FORM-006, PRINT-FORM-023 (geometry gate); PRINT-SUBSTRATE-007, PRINT-SUBSTRATE-008 (declaration-level; physical confirm in VALID-005); PRINT-LEGAL-014, PRINT-LEGAL-015, PRINT-LEGAL-016 (statutory point sizes, measured as point size); PRINT-FIDELITY-002 (composite of the above).

PRINT-VALID-003 — Assistable checks: tool flags candidates for human judgment

Level: SHOULD Applies to: all documents Source: our-implementation rule Source strength: industry practice Machine-checkable: partial Validation: For each assistable rule the tool SHOULD emit a candidate list with locations and the measured signal, and the review SHOULD be recorded as pass/fail/na by a human. Coverage = fraction of assistable rules with a working candidate detector.

For requirements a program cannot decide, the tooling SHOULD detect and flag candidates — narrowing the reviewer’s search rather than rendering a verdict — and SHOULD present each candidate with its page location and the raw signal that triggered the flag. Assistable checks include: caption/long-description equivalence to the source alt text (flag every /Figure with alt text but confirm the visible caption says the same thing); table header obviousness (flag tables whose header row lacks visual distinction); required-field redundancy (flag required markers that appear color-only); reading-order sanity on multi-column pages (flag where visual order and tag order diverge); link-destination adequacy (flag links whose anchor lacks the destination and page lacks a printed URL, per PRINT-FIDELITY-004). The tool MUST NOT report an assistable check as an automated “pass”; it reports “flagged for review” or “no candidates found.”

Rationale: Presenting a heuristic as a hard pass creates false confidence exactly where human judgment is required. Framing output as candidates keeps the human in the loop while still saving them from reading the whole document.

Implementation notes: These map onto existing surfaces: the audit/ACR tooling produces the candidate list; the tag-tree editor is where a human resolves each candidate against the live structure and geometry. Reuse the affordance detectors from PRINT-FIDELITY-001. Store review outcomes append-only (mirrors the existing human_verification audit table) so an ACR can distinguish “machine-passed” from “human-confirmed.”

PRINT-VALID-004 — Human-only checks (hand-fill usability, real-lighting glare, comprehension)

Level: SHOULD Applies to: all documents Source: our-implementation rule Source strength: industry practice Machine-checkable: no Validation: Structured human evaluation, ideally by a tester with the relevant disability; recorded as a checklist result. No automated signal is claimed.

Requirements grounded in physical, perceptual, or cognitive reality SHOULD be validated by a person, and — where feasible — by a person with the relevant disability, since lived experience surfaces failures a sighted, dexterous reviewer misses. This bucket includes: hand-fill usability (can a real person with a real pen, including tremor/low dexterity, complete every field — PRINT-FORM-001..004, PRINT-FORM-009); glare and legibility under real lighting on the actual substrate/finish (PRINT-SUBSTRATE-002, PRINT-TYPO-014); duplex/show-through in hand (PRINT-SUBSTRATE-001, PRINT-FORM-020); comprehension and plain-language adequacy (PRINT-LANG-001..006 — automated reading-level scores are a proxy, not a verdict). The pipeline MUST NOT claim these as validated on the strength of automated checks alone.

Rationale: These failures are invisible to the PDF object model: a field can be geometrically “big enough” and still be unusable next to a fold; a page can pass sRGB contrast and glare unreadably on gloss stock; text can score grade-8 and still confuse the reader. Only a human — best of all an affected human — catches them.

Implementation notes: Out of scope for automated tooling by construction. The pipeline’s job is to (a) route these to a human checklist, (b) supply the physical procedure in PRINT-VALID-005, and (c) record the result so the ACR states “human-evaluated” vs “not evaluated.” Where we cannot run a disability-informed test, say so in the report rather than implying coverage.

PRINT-VALID-005 — Physical-print verification procedure

Level: SHOULD Applies to: all documents Source: our-implementation rule Source strength: industry practice Machine-checkable: no Validation: Follow the procedure below; record substrate, printer, and per-check results. This is the ground truth that no object-model check can replace.

Before certifying a document print-safe for a real distribution, a physical verification SHOULD be performed:

Print at 100% / actual size — printer dialog set to “Actual size,” NOT “Fit to page” or “Shrink oversized pages” (confirms PRINT-SUBSTRATE-008). Print on the actual production substrate and finish (weight, color, matte/gloss), or the closest available, and duplex if the real piece is duplex.
Measure type — with a printer’s loupe or a point-size gauge, confirm body, footnote, and any statutory-minimum text meet their point-size rules on paper (PRINT-TYPO-001/003, PRINT-LEGAL-014/015/016). Physical measurement catches driver-side scaling that the object model cannot.
Grayscale pass — print one copy on a black-and-white device (or grayscale mode); confirm every color-borne distinction still reads (PRINT-COLOR-003/004) and required-field/error cues survive (PRINT-FORM-014).
Hand-fill test — with a real pen, attempt every form field, including under simulated low-dexterity conditions; confirm fill spaces, checkboxes, signature/date blocks are usable (PRINT-FORM-001..010).
Glare & lighting — read the printed sheet under overhead office light and near a window; check for glare on gloss and show-through on duplex (PRINT-SUBSTRATE-001/002).
Assembly hazards — staple/fold/hole-punch as the real piece will be, and confirm nothing encroaches the text block and landscape pages rotate sanely (PRINT-SUBSTRATE-005, PRINT-LAYOUT-013).

Record the printer, substrate, and pass/fail per step.

Rationale: The single most common print-accessibility failure — content silently shrunk below the minimum by a “fit to page” driver — is undetectable in the file and only appears on paper. Physical verification is the only check that closes the gap between the declared document and the delivered object.

Implementation notes: Structurally outside the automated stack. Provide this as an operator runbook and a printable checklist artifact the pipeline can emit alongside a print-intended document. The audit tool can pre-populate the checklist with its measured values (declared page size, measured point sizes) so the human is verifying against expected numbers rather than measuring blind.

PRINT-VALID-006 — Audit-tooling extensibility map: what our pipeline can and cannot cover

Level: SHOULD Applies to: all documents Source: our-implementation rule (framework) Source strength: industry practice Machine-checkable: no Validation: Governance/architecture review; kept current as tooling gains checks.

The following SHOULD be the honest map of where our existing stack — deterministic PDF a11y scanning (pikepdf + veraPDF), the audit/ACR-VPAT tooling, and the tag-tree editor — can be extended to cover a print rule, versus where it structurally cannot:

Extendable within the current stack (automatable, PRINT-VALID-002 methods): point size, leading, measure, margins (pikepdf content-stream + boxes); widget geometry and the docx→AcroForm geometry gate PRINT-FORM-023/024 (pikepdf AcroForm /Rect); page-size and scale-declaration checks (/MediaBox, /UserUnit); screen contrast (existing WCAG check) plus a new reflectance estimate for grayscale survival; presence-of-affordance and presence-of-compensation for the PRINT-FIDELITY-001 table (veraPDF structure + tag-tree walk); the composite print-safe-profile gate PRINT-FIDELITY-002.
Extendable as assistable only (PRINT-VALID-003): caption/long-description equivalence, table-header obviousness, reading-order sanity, required-field redundancy, link-destination adequacy. The tool flags; the human (in the tag-tree editor) decides.
Structurally out of reach — no automated tooling can cover, ever (PRINT-VALID-004/005): anything requiring the physical object or a human perceptual/cognitive judgment — print-at-100% as actually printed, hand-fill usability, real-lighting glare, gloss/matte finish, paper opacity/show-through, duplex-in-hand, binding encroachment, and genuine comprehension. These depend on the substrate, the printer driver, the lighting, and the reader — none of which live in the PDF. Our tooling can predict risk (e.g. flag a /UserUnit≠1 or a page not matching a standard size) but MUST NOT report these as verified.

Rationale: Being explicit about the automation boundary prevents scope creep toward a false “print-certification” product and prevents a green audit from being mistaken for print conformance. It also gives a clear backlog: the “extendable” items are legitimate tooling work; the “out of reach” items are permanently human/physical.

Implementation notes: This map drives the audit roadmap. New checks land as either an automatable check (with a PRINT-VALID-002 method and a rule ID) or an assistable candidate detector feeding the tag-tree editor. The physical/human items are wired to PRINT-VALID-005’s runbook and the append-only human-verification record, never to an automated pass. The flipbook is a screen artifact and is not part of print validation at all.