← Back to all articles

PDF/UA-1 accessibility, on by default, via API

SealDoc Team · · 4 min read

The European Accessibility Act (Directive 2019/882) has been in force since 28 June 2025. It is no longer a “we’ll get to it” item. Banks, telcos, e-commerce businesses with revenue above €10M, public-sector portals, and audiovisual media providers must deliver every customer-facing PDF in a form a screen-reader user can navigate. Penalties vary by member state but in NL and DE reach €100,000 per breach. The directive references EN 301 549, which references ISO 14289-1, which is PDF/UA-1.

We have been producing PDF/A-3 archives for two years. Adding PDF/UA-1 to the same output was always part of the plan; the EU mandate moved it from “useful” to “load-bearing for our compliance positioning”. As of today, every document SealDoc generates can come out as a tagged, screen-reader-friendly PDF/A-3u hybrid by sending one extra field on the request.

What changes

POST /api/documents/generate and POST /api/invoices/generate now accept an accessibilityLevel field. Default is "None", which preserves the byte-output of the existing flow. Set it to "PdfUa1" and the converter switches paths: tagged-PDF export with a structure tree, PDF/UA-1 metadata identifier, and a post-flight veraPDF check against ISO 14289-1.

POST /api/invoices/generate HTTP/1.1
Host: api.sealdoc.eu
X-Api-Key: ...
Content-Type: application/json

{
  "seller": { "name": "FeFem Holding B.V.", "vatNumber": "NL000000000B01", ... },
  "buyer": { "name": "Acme Corp", ... },
  "invoiceNumber": "INV-2026-001",
  "invoiceDate": "2026-05-07",
  "currency": "EUR",
  "vatRate": 0.21,
  "vatLabel": "21% BTW",
  "lines": [ ... ],
  "accessibilityLevel": "PdfUa1"
}

The response is the same jobId shape you already get back. The PDF you can then download has a structure tree, alt-text where applicable, table headers correctly tagged, and a language attribute. A screen-reader running over it announces “Invoice 2026-001. Bill to: Acme Corp. Subtotal: 1750 euro” rather than “Invoice 2026 001 Acme Corp 1750”.

What we measured

Before turning the flag on, we ran a 12-document corpus through the new pipeline and validated each output against verapdf -f ua1. The corpus covered minimal documents, simple and complex invoices, multi-language paragraphs, Unicode-heavy content, deeply nested headings, naked tables, tables with proper headers, nested lists, and a 50-section long document.

Results: 8 of 12 documents passed all 106 ISO 14289-1 rules. The remaining 4 passed 105 of 106 with the same single failure (clause 7.4.2, heading-nesting), caused by LibreOffice’s HTML importer promoting the first <h1> into the document Title metadata. Our invoice template in InvoiceHtmlBuilder uses styled paragraphs rather than mixed <h1>/<h2> headings, so it sidesteps that case entirely. A representative invoice in the new pipeline scores 106/106 with 2778 individual veraPDF checks all passing.

Why this matters strategically

The EU Accessibility Act is the kind of regulation that creates panic-purchase windows. Compliance officers are looking for solutions right now, vendor maturity is uneven, and most existing options are desktop tools (axesPDF Quickfix), enterprise-licensed Java libraries (iText with the Pdf/UA module), or manual remediation services billed per document. None of those are API-first, none of them produce a PDF/A-3 + PDF/UA-1 hybrid in the same call, and none of them are EU-sovereign by construction.

We built ours on LibreOffice’s native tagged-PDF export and veraPDF’s open-source Universal Accessibility validator. There is no commercial library involved. The marginal infrastructure cost over our existing PDF/A-3 pipeline is negligible. We can ship this at our existing price points without a margin hit.

What is in scope and what is not

In scope: documents and invoices that SealDoc itself generates from your structured input (Markdown, HTML, or invoice JSON). The template structure is under our control, the conversion path is under our control, and we can guarantee output quality.

Not in scope (yet): auto-remediation of arbitrary uploaded PDFs. Taking a 30-page prospectus that a graphic designer made in InDesign five years ago and inferring its semantic structure from layout heuristics is a multi-month research problem with uncertain output quality. We are not promising what we cannot deliver. If you need that, contact us — there are partner integrations that make sense.

Plan tier

PDF/UA-1 is a Growth-and-up feature (pdf_ua slug in your plan’s feature set). Free and Starter tiers continue to receive non-tagged PDF/A-3 by default. The flag is rejected with a 402 Payment Required if your plan does not include it, with the upgrade target named in the response so your client SDK can link to the right page.

If you are on Starter and an enterprise customer is asking you for accessible invoices: that is a Growth conversation, and we are happy to have it.

Validating it yourself

Every PDF/UA-1 output from SealDoc passes the same verapdf -f ua1 validator the EU Member States cite in their compliance audits. Download a generated PDF, run veraPDF locally, and you will see the same passedRules="106" failedRules="0" line we publish in our internal benchmarks. We do not ask you to take the marketing claim on trust; the validator is open source, the standard is ISO-published, and the output is binary-reproducible per request.

Sprint 53 ships PDF/UA-1 today. Sprint 53 was scoped at six and a half days of engineering work. We came in under budget because the existing converter pipeline already did most of the work; the marketing claim, “the only EU-sovereign API delivering Factur-X 1.0 plus PDF/UA-1 in one call”, is now actually true and validated.

← Back to all articles