WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Artifact tag vs. Change tag to artifact in Acrobat

for

From: Duff Johnson
Date: Mar 7, 2020 4:44PM

> I've now had the opportunity to take a look at four of the PDF tools for conversion and remediation: Acrobat Pro DC, Nuance PowerPDF Advanced now Kofax PowerPDF Advanced, Foxit for Business and the Microsoft conversion tool.
>
> All of them are breaking a TOC when the TOC is created to be accessible. This started some time after October 2018.

4 different tools broke in the same way around the same time….? Are you sure this is a PDF creator rather than a viewer issue?

> We are getting truncated TOC's that are difficult to slog through using adaptive technology. Likewise with Footnotes and Endnotes. What I see in all of the tools available mentioned above is the first Footnote or Endnote housing all of the Footnotes on the page or all of the Endnotes on the page and subsequent Footnotes or Endnotes being ignored. This is in the tagging, not the AT or the Viewer...this is apparently how all of the developers for the four tools mentioned above are interpreting the PDF standards.

I'm not clear what you mean by "ignored" - untagged?

Regarding footnotes and endnotes; these structures are not well-defined in PDF 1.7; this is true, and so implementations may differ, which is why the PDF Association has provided extended guidance on such topics in its Best Practice Guide. PDF 2.0 addresses the limitation in the specification.

> I have logged these bugs ad nauseum.

With what response?

> Either the specifications are not correct or every developer is interpreting them in the same incorrect way which is breaking the accessibility of a PDF document. I can't imagine that anyone would create a spec that breaks a TOC or lumps all Footnotes or Endnotes together with the first one then ignores all the rest.

Or, there's a bug in your viewer and you're seeing the same old footnote problem that we sought to address in PDF 2.0.

> There are also <Span> Tags randomly thrown into the Tags Tree containing content that shouldn't need a <Span>.
> When I convert from PowerPoint I can get <H1> Tags nested under a <Figure> Tag where there is no figure on the slide. I've had accessible Word documents recently have <Sect>, <Part> or now <Div> Tags for EVERY paragraph, bloating a Tags Tree and slowing down QA. Whatever happened to a clean Tags Tree...does anyone remember them?
>
> To be fair to the developers, it is difficult to code to a moving target or a specification that shifts 180 degrees with each iteration.

The PDF specification updated in 2008 and then in 2017… and a very modest revision will be published later this year. Tagged PDF was indeed updated in 2017… entirely necessary to resolve certain ambiguities (such as the footnotes issue) and to add support for other requested items such as redactions, line numbers, pronunciation hints, ARIA, MathML, namespaces, etc, etc.

> It is as if the conversion tools throw the content and the Tags up in the air and however they pair themselves is what I get...and what I have to fix...or have to try and read.
>
> Perhaps we need a specification that is less arduous to implement for developers? How can all developers make the same "mistakes"?

As above, I am curious about the ToC issue… I have a feeling it's a known bug in a single piece of software, but it would be good to understand the problem better.

> "We" can provide training to document authors and let the conversion/remediation tools developers know where the problems are BUT those of us with disabilities and accessible PDF content are still on the fringes of the radar 20 years after Acrobat 5 was introduced. I tell clients that the tagging tools we have today are worse than Acrobat 5. We've gone backward instead of forward.

I don't know… I think today's tools are far superior to those of the past. But progress is frustratingly slow; I entirely agree. This marketplace (accessibility) doesn't get much love from big software companies, sorry to say. The problem is 10 times harder due to the elephant in the room… authors who don't know / don't care to structure their documents, forcing software to try to account for users who use styles arbitrarily, make "footnotes" by hand, use tab-stops for "tables", etc, etc. All sorts of things that break accessibility IRRESPECTIVE of format. Some say that this is the developers' problem as well; they have to write software that trains the user to do the right thing, or somehow cleans up after the user. All these things are very hard to do when the developer is also trying to allow the author to express themselves.

> As I said in my previous post, it is one thing to have a seat at the table, it is another to be taken seriously and listened to. I am not sure we have either in the PDF universe.

> In the past year, when I look at a Tags Tree converted from an accessible document, it is like a dog's breakfast that needs more remediation than in the past.
>
> We can advocate for accessible digital content all we want, but if we don't have the tools that reliably convert one format to another, there is little we can do but support distribution in the source format when we create source documents to be accessible. As people with disabilities or who use adaptive technology to access digital content, we can advocate for what we need from digital content to be accessible but if we aren't part of the specification development/aren't taken seriously/listened to, our voices are unheard and we face a plethora of inaccessible content, in this discussion, inaccessible PDF. We are also then frustrated and discouraged thinking of further participation.


I get the frustration; you are right to be frustrated! There are certainly weaknesses in the specifications, but the experience comes from the software and the authors, not the spec, which simply defines types of structures.

Duff.