Tab order skips duplicate form fields (same field name) on a page

[rakunavi]

Hello all,

I would like to report a minor issue I encountered with the tab order of form fields in PDF-XChange Editor.

[Issue Description]
When multiple form fields on the same page have exactly the same field name, pressing the Tab key moves the focus only to the first field. The subsequent fields with the same name are skipped entirely.

• figure1.png

The same behavior occurs regardless of the selected Tab Order setting. However, it is especially noticeable when "Use Widget Order" or "Use Annotations' Array Order" is selected in the Page Properties, because in those modes I would expect the tab focus to follow the individual widgets or annotations on the page, rather than skipping visible fields only because they share the same field name.

• figure2.png

[Comparison with Adobe Acrobat]
In Adobe Acrobat, the tab focus moves correctly through all fields on the page according to the configured tab order, regardless of whether the field names are unique or identical.

[Expected Behavior]
When navigating a page with the Tab key, I would expect the focus to move through each visible form field widget that is reachable according to the selected Tab Order setting. This should also apply when multiple visible widgets share the same field name.
In particular, with "Use Widget Order" or "Use Annotations' Array Order", the current behavior seems difficult to reconcile with the fact that the skipped controls are separate visible widgets or annotations on the page. From a user's perspective, they appear to be distinct tab targets, so skipping the second and subsequent widgets with the same field name makes keyboard navigation unreliable for forms that intentionally use duplicated field names.

[Steps to Reproduce]

1. Create a text field on a page.
2. Open the "Create Multiple Copies of Fields" dialog, select "Use the same names," and create several copies of the field with the same field name.
3. Test the Tab Order options in the Page Properties, including "Use Widget Order" and "Use Annotations' Array Order."
4. For each setting, open the PDF in PDF-XChange Editor and navigate through the fields using the Tab key.
5. Observe that the focus skips the second and subsequent fields with the same name.
6. Save the file in PDF-XChange Editor.
7. Open the PDF saved in Step 6 in Adobe Acrobat Reader.
8. Press the Tab key in Acrobat Reader and confirm that the focus moves through the duplicate fields correctly.

• Animation.gif

• sample.pdf

Hoping that the above information will be of some help to you.
Thank you for your hard work on this great software.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 11.0.1
- Adobe Acrobat Reader Continuous Release Version 2026.001.21691
- OS Version: Windows 11 Pro / Home 25H2 Build 26200.8875
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[Daniel - PDF-XChange]

Hello, rakunavi

I believe this may be intended, fields with the exact same name will always mirror one another, and so there should be no reason to visit a second instance of the field when tabbing through them - especially on the same page where you can reasonably have observed the mirror action occur.

I will raise it with the Dev team to see what they think, but I am unsure this is something they will deem as needing a change.

As for the comparison to acrobat, I think, in testing their application - the issue is a bit more nuanced than it seems.
It looks to me like they are tabbing through all "visible" fields on the page, entirely ignoring anything else and essentially "emulating" the existence of a tab order where none is present.
I mention this because at no point does Acrobat attempt to tab to the next page in the file, which it should do if it was cycling through fields according to a tabulation order defined in the document. Instead it reaches a point where it changes focus to the entire page as a separate "object" from the fields, and then restarts cycling through the visible items on that specific page directly.

Perhaps we should offer something similar, once we have "visual order" logic wholly in place to utilize for such actions.. at least it is an item for consideration.

Kind regards,

[rakunavi]

Hello Daniel, thank you for contacting developers.

To help clarify how Adobe Acrobat actually handles page‑level tab order according to the PDF specification, I recorded a short verification video using a 6‑page sample file (shown at the beginning of this topic) configured as follows:

• Page 1: Unspecified
  Page 2: Use Row Order
  Page 3: Use Column Order
  Page 4: Use Document Order
  Page 5: Use Annotations' Array Order
  Page 6: Use Widget Order

• Animation.gif
  The capture software used (ScreenToGif) displays a yellow circle around the mouse cursor when the left mouse button is clicked
  and a red circle when the right mouse button is clicked, so you can tell which mouse button was clicked just by looking at the screen.

As shown in the video:

1. In Page Fit view, tabbing through Page 1 (Unspecified) moves the focus directly to Page 2. This occurs because Acrobat applies its fallback logic when no /Tabs entry is present.
2. Once on Page 2, even though Page 3 is not visible, the focus loops strictly within Page 2. This demonstrates that Acrobat is not “emulating visible fields,” but is correctly respecting the page’s /Tabs dictionary entry.
3. After zooming out so that Page 3 becomes visible, tabbing proceeds from Page 2 to Page 3, and continues all the way to Page 6. Acrobat pairs the page‑level /Tabs specification with the viewer’s current layout state, which is fully consistent with ISO 32000.

This shows that Acrobat does tab to the next page when appropriate, and that its handling of tab order is compliant with the specification.

The remaining issue is that PDF‑XChange Editor does not treat duplicate field widgets as independent tab targets under “Widget Order” or “Annotations' Array Order.” As demonstrated on Pages 5 and 6, Acrobat processes these widgets individually according to the spec. I hope the development team will consider aligning the Editor’s behavior with this widget‑level handling.

Furthermore, the assumption that “there is no reason to visit a second instance because it mirrors on the same page” does not hold in real‑world form usage. Long forms often place identical fields far apart, requiring scrolling to verify the mirrored value. More importantly, for screen‑reader users or keyboard‑only users, skipping visible interactive widgets makes the form unpredictable and prevents them from confirming that their data has correctly populated across all instances. This is a significant accessibility concern.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 11.0.1
- Adobe Acrobat Reader Continuous Release Version 2026.001.21691
- OS Version: Windows 11 Pro / Home 25H2 Build 26200.8875
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[Daniel - PDF-XChange]

Hello, rakunavi

Thank you for the added analysis - I will add this information and we will see how it goes.

Kind regards,