Signed PAdES output strips PDF/UA accessibility tags from uploaded document

[SachinthaHewawasam]

Summary

When a tagged, PDF/UA-compliant PDF is uploaded and signed through the Direct API, the PAdES document returned by DirectClient.getPAdES() no longer contains the original PDF accessibility/tag structure.

The accessibility metadata and structure are lost regardless of whether the input PDF is fully PDF/UA compliant.

Environment

• Library: signature-api-client-java

• Version: 7.0.3

• Signing API: Direct API

• Client: DirectClient

Observed Behavior

We uploaded a PDF generated using openhtmltopdf with PDF/UA accessibility properties configured.

The following differences were observed between the original PDF and the signed PAdES:

Property | Original PDF | Signed PAdES -- | -- | -- Producer | openhtmltopdf | iText 7.1.17 (Signicat AS) /StructTreeRoot | Present | Absent /Lang | nb | Absent PDF/UA identifier (pdfuaid) | Present | Absent DisplayDocTitle | true | Absent Page content | Normal page content | 13 flattened Form XObjects

The returned signed document is a PDF/A-3B document in which each page has been converted into a flattened Form XObject.

The original PDF is embedded in the signed document as:

Original-document-1.pdf

However, the tag structure from the original document is not present in the resulting signed PDF.

Reproduction / Verification

We verified that this behavior is not specific to the PDF generation or merge process by performing two separate signing tests:

1. Merged PDF

   • PDF was processed through pdfMergeActivity

   • The resulting PDF was then sent for signing

   • The signed output contained no PDF tag structure.

2. Raw openhtmltopdf PDF

   • A PDF generated directly by openhtmltopdf

   • The input PDF was fully PDF/UA compliant and contained /StructTreeRoot, /Lang, and pdfuaid

   • The PDF was sent directly to the signing API without any merge processing

   • The signed output again contained no PDF tag structure.

This indicates that the loss of the accessibility structure occurs during the signing/PAdES generation process rather than during our PDF generation or merge process.

Expected Behavior

Ideally, signing a PDF should preserve the existing PDF accessibility structure, including, where applicable:

• /StructTreeRoot

• /Lang

• PDF/UA identification (pdfuaid)

• DisplayDocTitle

• Tagged page content and associated accessibility metadata

The signed PAdES should remain PDF/UA compliant when the input document is PDF/UA compliant, provided that the signing operation itself does not require changes that invalidate the accessibility structure.

Question / Feature Request

Could you please clarify whether there is:

1. A configuration option or API parameter that allows the signing process to preserve the existing PDF tag structure?

2. A supported way to generate a signed PAdES while retaining PDF/UA accessibility information?

3. A planned feature or enhancement to preserve PDF/UA structures during PAdES signing?

If this behavior is controlled by the underlying signing infrastructure, could this issue be raised with the relevant signing/PAdES infrastructure team?

Impact

Our application is required to generate accessible documents in accordance with WCAG 2.1 AA and PDF/UA (ISO 14289) requirements.

The PDF submitted for signing is fully PDF/UA compliant. However, the signed document returned to the end user no longer contains the PDF tag structure required for accessibility.

As a result, accessibility is lost after the signing operation, which can prevent users relying on assistive technologies such as screen readers from accessing the signed document correctly.

Additional Information

We can provide the following artifacts if required:

• Original PDF/UA-compliant input document

• Signed PAdES output

• PDF structure inspection results

• Details of the signing requests used for both test cases

• signature-api-client-java configuration

[runeflobakk]

Hello @SachinthaHewawasam
Your accurately describe the current state wrt. WCAG and universal access in PAdES documents produced in Posten signering. The "wrapper" or envelope part of a PAdES will be "flattened" and loose accessibility structure. We are aware of the issue. So the short answer to your question about wether it is possible to produce a PDF/UA compliant signed document is regrettably "no".

A slightly more detailed answer is that this is something we are working on, but achieving accessibility (UU) compliance in PDFs, especially when taking one or more PDFs and adding elements to them (or machine-processing them in any way), is a difficult challenge to solve with 100% predictability regarding accessibility standards and WCAG. PDF is a "messy" format; adding a footer to every page to identify it as part of a signed document creates complications because it requires us to somehow "intervene" in the existing structure of the PDFs we receive and sign. Since the source documents can vary wildly, we have no control over their original structure, this is complex.

In our efforts to achieve accessibility compliance, we actually attempted some time ago to remove the footer stamped on each page of the original documents within the PAdES file, as it has no bearing on the validity of the signed signature itself. Strictly speaking, it was originally included merely to provide a sense of reassurance and visual branding indicating that the document was signed; it has absolutely no impact on the actual digital signature. However, we almost immediately received customer feedback insisting the footer to be restored, as without it, it wasn't obvious that the document had been signed. Consequently, we added it back.

What you see in a PAdES file received from Posten Signering is a "re-render" of the original documents; the pages displayed can never be more accessible than the files originally submitted. Therefore, a good starting point is, of course, to submit PDFs that already meet your desired level of accessibility compliance. As long as we are required to apply a footer to every page, we cannot avoid making adjustments to the display layer of the original documents to ensure this happens automatically and predictably. Unfortunately, at this stage, doing so will compromise accessibility (UU) and potentially WCAG compliance. However, work is underway to improve this situation. Posten takes accessibility very seriously and is focusing on it; specifically, we are addressing accessibility in the context of PAdES packaging within the service, though unfortunately, I cannot promise exactly when improvements will be implemented in the production environment. We are also working continuously on this with Digdir, as we are a standard component of the public sector administration of Norway, and are fundamentally required to meet accessibility standards.