Containers split into separate letters

First, after examining your PDF, it shows that the native source file was created in Word 2013 — an antiquated version of MS Word that had quite a lot of code-related quirks, including breaking up content as you described above. Since the first iteration of the PDF/UA standard was released in 2012 (a few months before Word 2013 was released), it's unlikely that MS considered the standard in Word 2013.

Second, I don't see the PDF Producer as "Adobe Acrobat PDF Library XX.X" or anything by Adobe, so I'm assuming that your office (or province of Canada) used Foxit (which is the standard PDF program for some Canadian provincial governments). A PDF Producer is the code module that creates the PDF from the source file.

I can't state here my professional opinion of Foxit's capabilities with accessible PDFs so I'll leave that to your imagination. But I will say the government IT decisionmakers should have listened to the professional opinion of several accessibility experts in Canada rather than to the sales pitches that promised a good cheap price. As always in life, you get what you pay for.

Suggestion: You might try upgrading to Word 365 and re-export the PDF using MS Word's built in Save As / PDF (Microsoft's internal PDF conversion utility), which might build a better, less-fragmented and more compliant PDF. The latest version of Word exports a better quality and more PDF/UA compliant PDF than earlier versions.

RE: the tag fragments...

The yellow container boxes within a <Tag> reflect how the content was coded during the PDF conversion (and sometimes how it was created by the author in the source file, such as Word). <Tags> wrap around content containers.

In theory, assistive technologies should be concerned only with the tags themselves, regardless how fragmented the content is. But some assistive technologies get hung up on the fragments, most likely because they are not fully PDF/UA-compliant ATs. So expect that some users will hear "why hour" rather than "your." You could argue that that's their problem, not yours. Everyone has the responsibility to follow the PDF/UA-1 standard, including AT manufacturers and end users.

RE: the chopped order in the architectural/construction Order panel...

.. are different numbers within the screen reader panel.

This panel shows the underlying construction of the content itself and reflects how the source program wrote the code in the source file and PDF. Although the PDF/UA-1 standard requires that AT follow only the Tags panel, the Order panel is used by some common technologies to present the content.  Your sample is very chopped up and I think that's due to how Word 2013 wrote its code 9 years ago. I'm going to assume that some technologies will choke on it and read your sample as "oh en che see omplete" instead as "once complete." Again, you could argue that that's their problem because they are not following the PDF/UA-1 standard to use the Tag Tree, not the Order panel.

However, given that you work for a government agency, that might not be in your best interests to serve the needs of your citizens.

Examine the Content panel...

The Content Panel shows exactly what's in the PDF file. Your sample PDF is one of the most insane messes I've seen.

*** And now, to add pure joy to your life, the expanded Content Panel in your sample PDF file.

What is this hot mess of nested code crud in your Content Panel?

What software program(s) would create such a convoluted mess?

• 4 nested container tags deep — throughout the entire document for every individual letter or small group of letters. Gah!
• The actual tag, such as <H2>, is buried in the deepest level where it will probably be skipped over by most technologies.

@CyndyB836, life is too short to spend it with this type of "blankety blank" code. This file will never be fully accessible to anyone using any technology. And I don't care what software checker passes it as compliant — Acrobat's built-in checker, PAC3, PAC 2021, CommonLook, Foxit.

Take a look at these 2 samples: I recreated the words "Once Complete" in MS Word 365 and did 2 exports, one using Adobe PDF Maker and the other using MS Word's built-in PDF export (File / Save As / PDF). Source Word files and exported PDFs are attached.

Both versions are a helluva lot better than yours, but I believe that in this test, Adobe PDF Maker makes a cleaner, more compliant PDF than the MS Save As method. But either one would be much more functional than what you're producing.

With Adobe PDF Maker:

With MS Word's built-in Save As / PDF utility:

A quick solution...

1. Upgrade your version of MS Word to Office 365.
2. Open your Word.docx file in the new W365.
3. File / Save As / PDF (and set options to accessible tagged PDF) to export a new, better PDF.
4. Open the new PDF in Acrobat or your PDF editing program of choice (I'm assuming Foxit?).
5. Test this PDF for accessibility, before you add the form fields. We call this version of a PDF form the "Visible Form Skeleton" and it should be fully accessible before form fields are added.
6. Add the form fields back in. In Acrobat, you can open the old PDF, select and copy the form fields, and paste them into the new PDF. But I don't know if Foxit has that capability. If it does, use it.
7. Finalize the form's accessibility.

Lesson to remember...

Never ever ever EVER add form fields to an inaccessible or poorly coded PDF. You're compounding the problems and wasting your time.

Best to you.