PDF/UA accessibility
The Convert to PDF and Archive as PDF/A-2 workflows produce PDF/UA-1 output as an option, and validate the result against ISO 14289-1. PDF/UA conversion is disabled by default, so an existing profile keeps its behavior until you enable it.
An accessible PDF carries a structure tree: it declares the reading order, the alternate text on figures, and the document language, so a screen reader conveys the document the way a sighted reader experiences it. PDF/UA-1 (ISO 14289-1) is the international standard for accessible PDF, and the basis organizations most often use to show a document meets an accessibility requirement. Those requirements come from law and differ by jurisdiction, so check your obligations with your legal advisers.
Supported workflows
PDF/UA output is available on two workflows:
| Workflow | Output | Conformance |
|---|---|---|
| Convert to PDF | Tagged PDF | PDF/UA-1 |
| Archive as PDF/A-2 | Tagged, archivable PDF | PDF/A-2a and PDF/UA-1 |
Tagging runs on the final output document, after the input files are collected or merged. A job that merges several inputs produces one result, tagged as a whole rather than per input file.
Configure PDF/UA output
Enabling PDF/UA changes what a profile costs to run. Review License page consumption before you enable it on a production profile.
To produce PDF/UA output for a profile:
- In the Workflows & Profiles tab, open the profile you want to edit.
- In the PDF/UA Conversion section, enable the option.
- Click Apply, then click Save & Restart Service in the notification that appears.
The section exists in the Conversion Service Configurator and in the Configurator Web, and contains two further settings:
- Figure Alt Text Prefix: The prefix for the generated placeholder alternate text on figures. Leave it empty to use the engine default.
- Validate result: Validates the output against ISO 14289-1 and raises a warning when the output doesn’t conform. Turned on by default.
The structure tree declares the language from the Default Language setting of the profile. To configure profiles in a container, review Configuring profiles in Docker containers.
Job options
Both settings are available per job:
| Type | Option | Description |
|---|---|---|
| Accessibility | PDFUA | Enable or disable PDF/UA conversion for the job. |
| Accessibility | PDFUAVALIDATE | Enable or disable validation of the PDF/UA output for the job. |
Job options apply to all documents processed in the same job. To review how job options are supplied, refer to Configure job and document options.
Conformance validation
Validation runs last, on the document the recipient receives, so the verdict describes the delivered bytes. Signing applies only on Archive as PDF/A-2. Each output document carries three properties:
| Property | Value |
|---|---|
PDFUA.CONFORMING | True or False |
PDFUA.FAILEDRULECOUNT | The number of failed requirements |
PDFUA.FAILEDRULES | The failed requirements in clause-test notation, for example 7.18.1-2 7.21.7-1 |
A document that doesn’t conform also raises the PdfUaNotConforming warning, which sets the job result status to warning. The job status itself stays completed. The job report, rather than a property, carries the per-requirement detail: specification, clause, test number, number of failed checks, and description.
Jobs delivered through a watched folder, an email connector, or the Simple API receive only the converted document. For those routes, the verdict appears in the service log and in the job report, not next to the output file.
Fail a job that doesn’t conform
The PdfUaNotConforming warning is a plain warning by default, so the job completes and delivers the document.
In the profile’s Events settings, the PDF/UA Not Conforming event has three values:
- Warning (default): The job completes and delivers the document.
- Error: The job fails, and only output connectors set to Error run. Choose this to deliver only documents that meet PDF/UA-1.
- Ignore: The service suppresses the warning.
To review the event severity settings, refer to Configure event behavior.
Features and limitations
Automatic tagging and automatic validation each have a boundary worth understanding before you rely on the output.
License page consumption
PDF/UA conversion doubles the license page consumption of a job:
| Workflow | Without PDF/UA | With PDF/UA |
|---|---|---|
| Convert to PDF | 1 credit per page | 2 credits per page |
| Archive as PDF/A-2 | 2 credits per page | 4 credits per page |
PDF/A conversion already counts each page twice, so a PDF/UA job on the archive workflow counts each page four times. To review how page credits are counted, refer to Conversion Service license, in Licensing documentation.
Generated alternate text is a placeholder
The alternate text generated for figures is a placeholder, not a description of the image content. A screen reader announces it, but it carries no meaning. Documents that must describe their images need a human to write those descriptions.
Validation covers machine-verifiable requirements only
Validation covers only machine-decidable requirements. The Matterhorn Protocol, the industry checklist for PDF/UA, classifies 87 of its 136 failure conditions as machine-determinable; the rest need human judgment: whether an alternate description is meaningful, whether the reading order matches the intended one, and whether a heading level reflects the document’s actual structure.
A document without findings isn’t automatically an accessible document. Treat a clean verdict as evidence that the mechanical requirements hold, not as a completed accessibility review.
Some failures are also inherent to the content, so repeating the conversion doesn’t resolve them: link annotations without an alternate description, signature widgets, blank pages, and fonts whose glyphs can’t be mapped to Unicode. A document in one of these categories stays non-conformant until the source document changes.
PDF/A and PDF/UA conformance
PDF/A-2a requires a tag tree to exist. PDF/UA-1 requires that tag tree to work. A file with one tag per page validates as PDF/A-2a and is still useless to a screen reader, which is why the service validates against PDF/UA-1 rather than against the archiving level.
On Archive as PDF/A-2, the tagging step runs before the PDF/A conversion that ends the workflow. That conversion repairs the metadata and color rules that tagging breaks, and writes the conformance level the document reaches. Enabling PDF/UA therefore often raises the archive conformance from PDF/A-2u to PDF/A-2a.
Deployment and processing time
PDF/UA output ships with every distribution: the Windows installer, the Docker images, and the Linux packages. The tagging and validation components ship with the product, so you don’t need a separate download or a Java installation.
The tagging engine supports 64-bit x86 only. Tagging adds processing time per document, because it reconstructs the document structure from the rendered pages. Validation runs under a two-minute limit per document and costs a small fraction of the tagging itself.