Matterhorn 25-001 · PDF/UA-1 UA1:7.15-1
Dynamic XFA forms: dynamicRender set to required
A dynamic XFA form has no static PDF representation, so its content is invisible to anything but the XFA renderer. PDF/UA-1 forbids it.
The condition, as the protocol states it. “File contains the dynamicRender element with value "required".”
Matterhorn Protocol 1.1, checkpoint 25, index 25-001, section UA1:7.15-1. Software can decide this one on its own.
What a screen reader actually does
The reader sees an almost-empty PDF, usually a "please upgrade your viewer" page.
What the file is
An XFA form is an XML application stored inside a PDF. The PDF’s interactive form dictionary carries it in an /XFA entry — either one stream, or an array of named packets:
/AcroForm <<
/Fields [ ]
/XFA [ (preamble) 21 0 R (config) 22 0 R (template) 23 0 R
(datasets) 24 0 R (postamble) 25 0 R ]
>>The config packet says how the form is to be rendered:
<config xmlns="http://www.xfa.org/schema/xci/3.0/">
<acrobat>
<acrobat7>
<dynamicRender>required</dynamicRender>
</acrobat7>
</acrobat>
</config>required means the form’s pages do not exist until an XFA processor lays them out from the template: sections grow, subforms repeat, pages are added as the data demands. The ordinary PDF pages in the file are a placeholder — usually a single page with a message to the effect that the viewer cannot display this kind of document. PDF/UA-1 clause 7.15 forbids this, and condition 25-001 is the test for it.
What a reader gets
The placeholder. A screen reader working from the PDF, a search index, or any viewer without an XFA renderer reads the PDF’s pages, and the PDF’s pages say please wait. Adobe’s own explanation of form types is that dynamic forms cannot be rendered by the built-in PDF viewers of modern browsers.
Acrobat can render it. But its accessibility tooling does not apply: Adobe states that the Prepare for accessibility action runs on all PDFs except dynamic XFA forms and portfolios (Create and verify PDF accessibility). There is no tag tree to inspect, because the content a tag would describe is not in the PDF.
Where it comes from
Adobe’s form designer — LiveCycle Designer, now AEM Forms Designer. Adobe’s documentation describes the choice it offers at save time: Adobe Dynamic XML Form produces a dynamic form, Adobe Static PDF Form a static one. Dynamic is the option for forms whose tables grow and whose sections repeat as they are filled in.
How to check it free
A browser’s built-in viewer. Open the file there. A dynamic form shows its placeholder instead of the form.
veraPDF. Its PDF/UA-1 rule set has rule 7.15-1, dynamic XFA forms shall not be used, tested on the value of dynamicRender.
Reading the packets. qpdf --qdf --object-streams=disable form.pdf plain.pdf decompresses every stream, including the XFA packets. Search the output for dynamicRender. required is this condition; forbidden, or no element at all, is a static form.
How to fix it free
There are two routes, and neither is a repair of the existing file.
Re-save it static, if you have the design file. In AEM Forms Designer, save the form as Adobe Static PDF Form instead of Adobe Dynamic XML Form — the two options Adobe’s form-types explanation describes. A static form’s layout is fixed at design time, so anything that relied on growing — a table that adds rows as you type — has to be redesigned to fit a fixed page. The result still has to be tagged and checked like any other form.
Rebuild it as an AcroForm, if you do not. Adobe documents that Acrobat Pro 2020 and later cannot edit XFA data directly, and gives two workarounds: Print to Adobe PDF, or Save As → Encapsulated PostScript and reopen the result (Unable to edit XFA forms). Both flatten the form: every field, button and script is lost, and what remains is the rendered pages — the form as it looks with whatever data it held. From there:
- Choose
All tools → Prepare a form, select the flattened file and choose Create form; Acrobat puts fields over the blanks it detects (Convert documents to PDF forms). - Give every field a tooltip, condition 28-005.
- Tag the document —
All tools → Prepare for accessibility → Automatically tag PDF— and check that each field sits in a<Form>element, condition 28-010.
Flatten the blank form, not a filled one, or the rebuild starts with somebody’s data printed on it.
Where Taggart differs
Taggart reads the /XFA entry of the interactive form dictionary and looks for <dynamicRender>required</dynamicRender> in it, ignoring case and spacing:
The AcroForm contains an XFA packet declaring
<dynamicRender>required</dynamicRender>. A dynamic XFA form has no static PDF representation and cannot conform to PDF/UA-1.
It is a blocker, there is no repair, and while it stands Taggart refuses to write the PDF/UA identifier into the file, however many other repairs succeed. Everything else in the same report describes the placeholder page — which is accurate, and is also the point.
The check reads /XFA in either of the forms the PDF specification allows — one stream, or an array of named packets like the one above, whose streams it reads in turn — so a form split into packets is checked the same way as one held in a single stream. A static form, with dynamicRender set to forbidden or absent, is not reported.
How Taggart handles it
Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.
Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.
Frequently asked questions
How can I tell whether a PDF is a dynamic XFA form?
Open it in a browser's built-in PDF viewer. Adobe's own documentation says dynamic XFA forms cannot be rendered there, so what you see is a placeholder page rather than the form. To be certain, look in the XFA config packet for dynamicRender with the value required.
Is static XFA allowed?
PDF/UA-1 forbids only the dynamic kind. A static XFA form has a fixed layout and a real PDF page description, so it is not this condition, though it still has to meet every other requirement. XFA as a whole is deprecated in PDF 2.0, which is a reason to prefer an AcroForm for anything new.
Can Acrobat convert it?
Not directly. Adobe documents that Acrobat Pro 2020 and later cannot edit the XFA data, and that its workarounds — printing to Adobe PDF, or saving as Encapsulated PostScript — flatten the form and lose its fields and scripts. That gives you a page to rebuild the fields on, not a converted form.
Can Taggart fix it?
No. There is nothing in the file to repair into a static form: the layout exists only as instructions to the XFA renderer. The form has to be re-saved from its design tool or rebuilt.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 25 (XFA), index 25-001 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.15-1 |
| WCAG 2.1 | 4.1.2 Name, Role, Value — Level A |
| EN 301 549 / Section 508 / ADA Title II | All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them. |
Related conditions
- 24-001 Non-interactive forms are not tagged with the PrintField attributeA printed form — checkbox squares, signature rules, fill-in lines drawn on the page rather than implemented as widgets — needs /PrintField attributes so a reader can describe the control.
- 28-010 A widget annotation is not nested within a Form tagEvery form control must sit inside a Form structure element.
- 28-005 A form field has neither a TU entry nor an alternative descriptionThe /TU tooltip is the accessible name of a PDF form field. Without it the field has no name at all — the visible label printed next to it is not connected to the control.
Other conditions in checkpoint 25
Checkpoint 25 covers xfa. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
Check your own file. Taggart’s validator is free and unlimited — 75 of the 87 Matterhorn conditions software can decide, with the other 12 listed for you to confirm; no watermark, no expiry, and no account needed up to 60 pages.
Checked with Taggart on a generated file that fails this condition on . The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated .