Hello!
I've attached the document I am working on - for the accessibility experts it's not finished, so please don't worry about the "Structure Tree" issue if you run the document through PAC3.
When working on this document I have come across this issue where some of my tags separated into individual letters:
In other editing programs (like Foxit) you can use an "Edit Object" tool and it allows you edit the sentence or phrase by pasting the contents of one blue box together, this will amalgamate the containers in the Content, Tags and Reading Order tabs.
I know that if the letters are separated like this into different containers like this it doesn't really hinder screen readers unless it breaks up words such as "your", where if it it's split up into each letter, the screen reader will USUALLY say "your" but if it's broken up so that the y and our are separated the screen reader will say "y" & "our". Meaning if parts of the tag that is broken up is an actual word this causes a problem.
Another problem this is causing me is each of the containers within the tags are different numbers within the screen reader panel.
How do I fix this in Adobe Acrobat WITHOUT having to open the document into Foxit and use the "Edit Object" trick described above OR using the "Edit PDF" tool to simply delete the text that is broken apart and typing it right back into the PDF - hoping this doesn't cause font to not be embeded, and then trying to embed that text, without losing all your previous work or have that font embed correctly but it work in Adobe, but if you open the document in another program (like Foxit or Nuance) that font somehow is NOT embeded?
Thank you anyone for your help!
@Bevi Chagnon - PubCom.com I know you have been able to answer all my questions lately and you seem to have quite a bit of expertise in issues that appear when trying to create Accessible PDF and Forms
Thank you again!
Cyndy
3
Replies
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...
- Upgrade your version of MS Word to Office 365.
- Open your Word.docx file in the new W365.
- File / Save As / PDF (and set options to accessible tagged PDF) to export a new, better PDF.
- Open the new PDF in Acrobat or your PDF editing program of choice (I'm assuming Foxit?).
- 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.
- 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.
- 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.
@Bevi Chagnon - PubCom.com I know you have been able to answer all my questions lately and you seem to have quite a bit of expertise in issues that appear when trying to create Accessible PDF and Forms
By @CyndyB836
Yes, I've been accused of that!
https://www.pubcom.com/associates/index.shtml
I'm always glad to help others make accessible ICT. It's one of my life passions.
AdChoices