European Accessibility Act document pipeline checklist

The European Accessibility Act does not make every business document automatically subject to one universal PDF rule. It requires covered products and services placed on the EU market to meet applicable accessibility requirements from 28 June 2025, subject to scope, national implementation, transition rules, and exemptions. Engineering teams should identify which service a document belongs to, map the applicable requirements, create accessible source structure, test the output with more than one method, and retain evidence for the exact artifact released.

This is an engineering checklist, not legal advice. Scope, enforcement, penalties and exemptions depend on the service and the member state's law. Ask qualified counsel to interpret your obligations.

Start with the Directive's actual scope

Directive (EU) 2019/882 applies to named products and services. Covered services include areas such as electronic communications, certain passenger-transport services, consumer banking, e-books, and e-commerce. Article 4 requires the covered products and services to meet the accessibility requirements in Annex I.

The Directive required member states to apply their transposing measures from 28 June 2025. It also contains transition provisions and an exemption for microenterprises providing services. Those details matter. A document is not in scope merely because it is a PDF or because a recipient is in the EU; it must be evaluated in the context of the product or service through which it is provided.

Ask these questions before changing a renderer:

1. Which product or service provides the document?
2. Is that product or service within Article 2?
3. Which economic operator is responsible for the information?
4. Which member-state law applies?
5. Do transition, microenterprise, fundamental-alteration, or disproportionate-burden provisions apply?
6. Which harmonized or referenced standard is being used to demonstrate conformity?

Do not encode a legal conclusion such as eaaRequired: true from geography alone.

What does Annex I require from information?

Annex I requires information supplied with covered products and services to be perceivable, operable, understandable, and robust. It calls for information through more than one sensory channel, understandable presentation, adequate font characteristics and contrast, text formats that can generate alternative formats, and alternatives for non-text content.

For document systems, those requirements translate into source and output controls:

Requirement area	Document-pipeline control
Structure	Preserve headings, lists, tables, captions, and reading order as semantics rather than appearance alone.
Text alternatives	Require meaningful alternatives for informative images and mark decorative images appropriately.
Language	Set the document language and identify language changes when supported.
Navigation	Provide headings, bookmarks, links, labels, and logical focus order where the format supports them.
Forms	Associate labels, instructions, validation messages, and field purpose with controls.
Visual presentation	Check contrast, font size, spacing, zoom behavior, and reflow requirements that apply to the delivery surface.
Compatibility	Test with assistive technologies and applications used by the intended audience.

A visual review alone cannot confirm these properties because tags, alternative text, field labels, and reading order may be invisible on screen.

Treat standards as an evidence method

Organizations commonly use EN 301 549 and WCAG criteria when designing and testing accessible ICT. The W3C maintains WCAG standards and supporting documents. For PDF-specific work, PDF/UA provides a format-oriented conformance model, while WCAG techniques address user-facing accessibility outcomes.

These sources serve different purposes. A validator can find machine-detectable failures, but it cannot decide whether alternative text is useful, reading order conveys the intended meaning, or the business content is correct. A conformance claim should identify the standard, version, scope, test method, exceptions, and date.

Build accessibility into the source model

Repairing a finished PDF is slower and less reliable than carrying semantics through the source model. Define requirements before rendering:

type AccessibleFigure = {
  kind: "figure";
  sourceRef: string;
  alternativeText: string;
  decorative: boolean;
};

type AccessibleTable = {
  kind: "table";
  caption: string;
  headerRows: number;
  headerColumns: number;
  cells: Array<Array<string>>;
};

The exact renderer schema will differ. The important decision is that heading level, table headers, language, captions, and text alternatives are data with validation rules. They should not be inferred from font size after the file is complete.

Reject contradictory input such as a decorative image with nonempty alternative text or a data table with no header definition. Route ambiguous descriptions to review rather than allowing a model to invent them without context.

Use a layered test plan

An accessible-document release should combine checks because no single tool covers every requirement.

1. Source validation

Confirm that required semantic fields exist, heading levels are coherent, table headers are declared, links have descriptive labels, and the language is set.

2. Format validation

Run the official or accepted validators for the target format and profile. Keep the full report, tool version, ruleset version, and artifact hash.

3. Application inspection

Open the exact file in the applications your recipients use. Inspect the tag tree, reading order, bookmarks, form fields, and document properties.

4. Assistive-technology testing

Complete representative tasks with at least the screen reader and platform combinations in your acceptance profile. Test navigation and comprehension, not only whether text is announced.

5. Human content review

Check alternative text, link purpose, heading meaning, table comprehension, reading sequence, and error instructions. These are editorial and usability decisions.

6. Exact-artifact release

Bind approval to a SHA-256 digest and verify the digest again at delivery. Regeneration after approval produces a new candidate, even when the source data looks unchanged.

Handle recurring documents as a versioned workflow

Invoices, statements, disclosures, and reports are recurring jobs. Their accessibility controls should be part of the saved job definition:

approved template + semantic data contract + renderer version
  -> candidate artifact
  -> structural validation
  -> application and assistive-technology sampling
  -> review decision bound to artifact hash
  -> release and evidence retention

Version the template, renderer, fonts, assets, validator rules, and acceptance profile. A change to any of them can alter accessibility and should trigger the appropriate regression set.

The evidence guide explains the exact-byte boundary. The governance guide covers review and release controls without copying sensitive content into public records.

Runstamp's current boundary

Runstamp exposes qualified PDF operations, including pdf.render and pdf.validate, through the public operation contract. Each operation page states its input and output summary, declared errors, losses, execution surfaces, checked example, and limitations.

Those operations do not create a legal conclusion and do not prove end-to-end accessibility for every document, application, assistive technology, or jurisdiction. Product teams remain responsible for the acceptance profile, representative files, legal interpretation, human review, and release decision.

Implementation checklist

• Confirm legal scope for the service and member state.
• Name the standard, version, profile, and test tools used for evidence.
• Make semantics required fields in the source model.
• Keep untrusted content separate from templates and accessibility policy.
• Validate the source before rendering.
• Run format validators against the exact output bytes.
• Test representative tasks in destination applications and assistive technologies.
• Review alternative text, link purpose, reading order, and table comprehension.
• Bind the approval and release record to the artifact hash.
• Re-run the acceptance set when templates, fonts, renderers, or validators change.

For the surrounding release controls, use the governed document release model and the security boundary.