Accessibility and structure / Reading order
Reading order in an accessible PDF
The sequence a screen reader speaks the document in, which comes from the order of elements in the structure tree and not from where anything sits on the page.
Where this API stands
This API does not produce this standard, and there is no option that would. What follows is what the requirement actually is and where a rendered document stands against it. There is no structure tree written by this API, so there is no reading order in it to be right or wrong. The thing that matters here, and that you fully control, is that DOM order in your source markup is what any tagging pass will use as its starting point. That makes CSS which reorders content visually the specific hazard: `order` on a flex child, an explicit `grid-area`, a float, or an absolutely positioned block all move the ink without moving the markup. The visual result is fine and the reading order silently diverges from it, and no downstream tool can detect the divergence because both versions look correct from where it stands.
What the standard requires
The requirements as a checker enforces them, rather than as a procurement document paraphrases them. A file satisfies all of these or it satisfies none of them.
- The order of children under /StructTreeRoot is the reading order, top to bottom, and nothing about the visual layout changes it.
- Every page carries /StructParents so its marked content can be located in the tree, otherwise the content is orphaned and read in whatever order the tool guesses.
- Content that appears in more than one place visually, such as a repeated column heading, appears once in the tree.
- Sidebars, pull quotes and captions sit where a person would read them, which is a judgement call rather than a mechanical rule.
- Anything that is not part of the reading order, such as a page number, is marked as an artifact and therefore has no place in the tree at all.
Who asks for this
The same accessibility audits that ask for tags, and this is the checkpoint they most often fail on. A structure tree can be present, complete and in the wrong order, and a mechanical validator will pass it because nothing in the file is malformed. The failure shows up when a person listens to the document and the totals are read before the line items.
What to do about it
Write the markup in the order the document should be read, then use CSS to place it. That is free, it happens before any tool is involved, and it is the only part of reading order that is cheap to fix. Where a layout genuinely needs a visual order different from the reading order, note it for whoever does the remediation, because they will otherwise reproduce the visual order and think they are being faithful.
How to check a file rather than assume
PAC 2024 has a reading order preview that walks the tree and numbers the content in sequence over the page image, which makes a wrong order obvious in a second. Acrobat's Reading Order tool does the same thing and lets you drag elements into place. Neither can tell you the order is wrong on its own, because only a person knows what the document meant.
The mistake people make here
Building a two-column layout with floats or a grid and letting the markup follow the visual columns. It reads correctly on screen because the eye tracks columns, and it reads as interleaved nonsense to a screen reader because the tree alternates between them. Multi-column content is the single most common source of a reading order failure.
Frequently asked
Does this API produce Reading order?
Not produced by this API. There is no structure tree written by this API, so there is no reading order in it to be right or wrong. The thing that matters here, and that you fully control, is that DOM order in your source markup is what any tagging pass will use as its starting point. That makes CSS which reorders content visually the specific hazard: `order` on a flex child, an explicit `grid-area`, a float, or an absolutely positioned block all move the ink without moving the markup. The visual result is fine and the reading order silently diverges from it, and no downstream tool can detect the divergence because both versions look correct from where it stands.
Can I turn on the pdf_a option and be done?
No. The option writes an XMP packet declaring PDF/A-1b into the document catalogue, and the render response comes back carrying a warning that says in as many words that this is best-effort and that full conformance requires tagged structure and an embedded ICC profile. It is a claim written into the file, not a certificate earned by it, and a validator checks the claim against the bytes. Read the warning array in the response rather than taking the absence of an error as a pass.
Should I convert before rendering or after?
After, always. A conformance converter rewrites colour, embeds profiles, sets boxes and stamps metadata on a finished PDF. Trying to satisfy a conformance target from the source side means guessing at what the converter would have done, and the guesses that go wrong are expensive: flattening transparency you did not need to flatten changes what the page looks like.
Standards this one is confused with
The neighbours that matter are the ones people mistake for this, not the ones that sort next to it.
The logical structure tree in a PDF
The tree of typed elements, Document at the root and paragraphs, lists, tables and figures below it, that describes what the document is made of.
PDF artifacts: page furniture that is not content
The distinction between content that belongs in the reading order and page furniture that does not, marked in the content stream so a screen reader can skip the furniture.
How to tell if a PDF is tagged
A tagged PDF carries a second, invisible copy of itself: a tree of headings, paragraphs, lists and cells that says what the content is, rather than where the ink goes.
PDF/UA-1 compliance for a generated PDF
ISO 14289-1: the standard that says a PDF is usable by assistive technology, which in practice means it carries a complete and correct structure tree.
Alt text on images in a PDF
A text description attached to a figure structure element, which is what a screen reader speaks in place of an image it cannot see.
Every standard, with what this API does about it
The full list, grouped by what the requirement is for, each marked with how far this API gets.
What this API actually does
One page per option and endpoint that exists, with nothing that does not.
Conformance is decided after a file exists. Render the document, then check it, then convert only what the checker actually flags.