Exstream design metadata determines the heading structure, table semantics, reading order, language, and alternate text exposed to assistive technology. The object names and limitations below describe the historical classic implementation; the core model is corroborated by current documentation, but version-specific constraints must be checked against your release.
Accessibility is a per-output-object decision
Tagging is enabled on the PDF output object. It is not inferred from visual placement, and each output object used for accessible production must be configured independently. An estate can easily have one accessible statement queue and five untagged ones, all rendering the same design.
The defaults matter: text in paragraphs, text boxes, and table cells is read by default.
Images, charts, and shapes are skipped by default and represented as artifacts unless the design supplies alternate text and a read option exposing them.
An object marked Do not read text is omitted from the reading stream, and excluding a parent object excludes everything embedded in it, which is a common source of silently missing content.
Semantics must be applied deliberately
A heading that is visually large but structurally a regular paragraph conveys no hierarchy to a screen reader. Apply heading tags with levels so assistive technology can distinguish a document heading from a section heading. Lists likewise need explicit list tagging; the default treats list content as ordinary paragraphs.
For tables, the engine creates table, row, and data-cell structure automatically for supported table objects. Header cells the table configuration does not recognize can be assigned a table-header tag manually. Avoid blank rows, columns, and cells that carry no meaning; each one is noise in the reading sequence.
Set reading order explicitly
The read order is separate from visual coordinates. Historically the default followed object insertion order, with the accessibility viewer exposing markers for inspection and manual rearrangement, and the read order also drove tab order.
Insertion order is a fossil of how the template was built, not of how it should be read. Any design with captions, image descriptions, side panels, or multiple columns needs its read order set explicitly, or the screen reader will narrate the page in the order a developer happened to add objects years ago.
Language is part of accessibility
The reading language inherits from the application's default locale language object, and a page, design object, or text paragraph can override it. The override applies to whole paragraphs, not arbitrary word ranges. For non-textual objects, language affects how alternate text is pronounced. Multilingual documents built from language layers or localized page objects need matching accessibility-language settings, or a Czech paragraph gets read with English pronunciation rules.
Know the output constraints
The accessibility contract has hard edges, and in the historical engine these included: multiple-up output disables tagging, PDF/VT does not support tags, and overlay creation and some image-based modes are incompatible with tagged output. PDF/A-1a and PDF/A-2a required or auto-enabled tags; PDF/A-1b treated them as optional. These compatibility rules are exactly the kind of version-sensitive detail to re-verify per release; see also the archive article on CE 25.3 PAC findings for a current example.
Validate with assistive technology, not with your eyes
A visually correct page can still have wrong hierarchy, missing alternate text, wrong language, or scrambled order. Validation means running the actual PDF through an accessibility checker and an assistive-technology workflow, on production output, at every release that touches the design, the driver, or the engine. Run these checks in the regression pipeline whenever the design, output driver, or engine changes.