Matterhorn 28-009 · PDF/UA-1 UA1:7.18.3-1
Tab order that follows the page, not the document
/Tabs is present but set to /R (row order) or /C (column order) rather than /S (structure order).
The condition, as the protocol states it. “A page containing an annotation has a Tabs entry with a value other than S.”
Matterhorn Protocol 1.1, checkpoint 28, index 28-009, section UA1:7.18.3-1. Software can decide this one on its own.
What a screen reader actually does
Tab order follows geometry rather than logical structure — in an RTL document, catastrophically so.
What is in the file
Each page dictionary may carry a /Tabs entry, and it takes one of three values:
/Tabs /S structure order — the tag tree decides
/Tabs /R row order — left to right, top to bottom, by geometry
/Tabs /C column order — top to bottom, then acrossPDF/UA-1 clause 7.18.3 requires /S on any page that contains an annotation. This condition fires when the entry is present and is /R or /C.
It is per page. A twenty-page form can have the right value on the page somebody was looking at and the wrong one on the other nineteen, which is the usual shape of it.
What the user does
Tab through a form and the caret goes somewhere. Which somewhere depends entirely on this one name.
With /S it follows the structure tree, which is the same order a screen reader reads — so the announcement and the caret agree, and the field a person hears described is the field they are about to type into.
With /R it follows geometry. On a two-column form that means: first field of the left column, first field of the right column, second field of the left column, second of the right. The person hears “Surname” and lands in “Postcode”. They are not lost in a way they can see; they are filling in a form whose labels and boxes have come apart, and the mismatch is announced to them as if it were correct.
The same page read by a screen reader in reading mode is in structure order. So the document says one thing when read and does another when operated. That gap is the failure, and it is invisible to anyone using a mouse.
The right-to-left case
/R means left to right. That is not a neutral default in a Hebrew or Arabic form — it is backwards.
A Hebrew form is filled from the right. With row order, the first field on each row that Tab reaches is the last one the person should fill, and the last one it reaches is the first. Every row, every page. Combined with labels sitting to the right of their fields, the result is a form where the tab sequence, the visual order and the announced label all disagree with one another in different ways.
This is why the setting is not a detail. In a left-to-right single-column form it is a technicality. In a right-to-left two-column form it is the whole usability of the document.
How to check it free
Tab through it. Open the form, press Tab repeatedly, and watch where the focus goes. If the sequence is not the order you would fill the form in, the entry is wrong. This takes fifteen seconds and needs nothing installed.
Acrobat Pro: Page Thumbnails panel → select a page → right-click → Page Properties → Tab Order. The radio button shows the current value. Check more than one page.
veraPDF reports it against clause 7.18.3, per page, which is how you find the nineteen pages nobody looked at.
How to fix it free, in Acrobat Pro
- Open the Page Thumbnails panel.
- Ctrl+A to select every page — this is the step that matters.
- Right-click → Page Properties → Tab Order tab.
- Choose Use Document Structure.
- Save.
Then confirm the structure it is now following is worth following. Setting tab order to structure order on a form whose controls are not in the structure tree hands the caret to a tree that does not contain them, which is not an improvement. Fix the structure first, then point the tab order at it.
Where Taggart differs
tab-order is a safe fix: it writes one name into each page dictionary, changes no content and no appearance, and the gate confirms the rendering is identical. It runs in the batch.
What Taggart adds is the ordering. Setting /Tabs /S is only meaningful once the annotations are in the structure tree, so it is sequenced after annotation-structure rather than alphabetically or by page — and the remediation report records both, together, because a reviewer looking at “tab order set to structure” wants to know that the structure existed when it was set.
It also reports the pages, not just the document:
/Tabs is /R on 19 of 20 pages. Page 1 is already /S.
That asymmetry is the fingerprint of a setting changed by hand while looking at one page, and naming it is usually enough for somebody to recognise what happened.
How Taggart handles it
Taggart detects this condition automatically. It is reported as a blocker, with the page, the structure path and the object id of every occurrence.
The fix is Set tab order to structure order. It is mechanical, so “Fix All Safe” applies it in bulk with a diff and a single undo.
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
Where is this setting in Acrobat?
Page Thumbnails panel, select all pages, right-click → Page Properties → Tab Order → Use Document Structure. It is per page, which is why it is so often right on page one and wrong on the rest — somebody set it while looking at a single page.
Does it matter if the form is simple?
On a single column of fields in top-to-bottom order, row order and structure order agree and nobody notices. The setting still fails the standard, and it is one right-click away, but the lived effect is nil. On two columns it is the difference between a usable form and an unusable one.
What if /Tabs is absent entirely?
Absent is a different condition. PDF/UA-1 requires /Tabs to be present and set to /S on any page carrying an annotation, so an absent entry fails too — Taggart reports it separately because the repair is the same but the diagnosis is not.
Why is this worse in Hebrew?
Row order means left to right. A Hebrew form is filled right to left, so row order does not merely differ from the logical order, it reverses it — the first field a person should reach is the last one Tab arrives at, on every row.
Where this sits in the standards
| Standard | Reference |
|---|---|
| Matterhorn Protocol 1.1 | Checkpoint 28 (Annotations), index 28-009 |
| PDF/UA-1 (ISO 14289-1) | Clause 7.18.3-1 |
| WCAG 2.1 | 2.4.3 Focus Order — 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
- 28-010 A widget annotation is not nested within a Form tag Every form control must sit inside a Form structure element.
- 28-002 An annotation is not a direct child of an Annot structure element Non-widget, non-link annotations must sit inside an Annot structure element so they have a place in the reading order.
- 09-001 Tags are not in logical reading order The order of elements in the structure tree does not match the order a human would read the page. This is the single most common substantive defect in tagged PDFs and the one Acrobat's own tooling handles worst.
- TG-RTL-004 Reading order is not right-to-left aware Auto-tagging tools order blocks left-to-right, top-to-bottom. In a Hebrew two-column layout the correct order is right column first.
Other conditions in checkpoint 28
Checkpoint 28 covers annotations. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.
- 28-001 An annotation is not in correct reading order The annotation's position in the structure tree does not match where it appears on the page.
- 28-002 An annotation is not a direct child of an Annot structure element Non-widget, non-link annotations must sit inside an Annot structure element so they have a place in the reading order.
- 28-003 An annotation is used for visual formatting but is not tagged according to its semantic function A Square or Line annotation used to draw a box round a callout is decoration and should be artifacted, or tagged for what it actually means.
- 28-004 An annotation has neither a Contents entry nor an alternative description Every non-widget annotation needs an accessible description, either in its own /Contents or in the /Alt of the structure element that encloses it.
- 28-005 A form field has neither a TU entry nor an alternative description The /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.
- 28-006 An annotation with subtype undefined in ISO 32000 does not meet 7.18.1 A custom annotation subtype still has to be placed in the structure tree and described.
- 28-007 An annotation of subtype TrapNet exists TrapNet annotations are prepress artefacts and are forbidden in PDF/UA-1.
- 28-008 A page containing an annotation does not contain a Tabs entry Any page carrying annotations must declare a tab order. PDF/UA-1 requires /Tabs /S — tab order follows the structure tree.
- 28-010 A widget annotation is not nested within a Form tag Every form control must sit inside a Form structure element.
- 28-011 A link annotation is not nested within a Link tag A link annotation must be a child of a Link structure element containing the link's text, joined by an object reference (/OBJR).
- 28-012 A link annotation does not include an alternate description in its Contents entry Link annotations need /Contents describing where the link goes.
- 28-013 An IsMap entry is true but the functionality is not provided in some other way A server-side image map requires pointing at a pixel, which is not possible without a mouse.
- 28-014 CT entry is missing from the media clip data dictionary The media clip's content type (/CT) is required so a processor knows what it is being asked to play.
- 28-015 Alt entry is missing from the media clip data dictionary Media clips require an /Alt array giving a text description.
- 28-016 File attachment annotations do not conform to 7.11 The file specification referenced by a FileAttachment annotation must carry both /F and /UF.
- 28-017 A PrinterMark annotation is included in the logical structure Crop marks and registration targets are production artefacts and must not appear in the structure tree.
- 28-018 The appearance stream of a PrinterMark annotation is not marked as Artifact The content inside a PrinterMark's appearance stream must itself be artifacted.
Check your own file. Taggart’s validator is free and unlimited — every machine-checkable Matterhorn condition, no page cap, no watermark, no account needed.
Verified against a real document on . Last updated .