WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?

for

From: Duff Johnson
Date: Apr 8, 2020 12:53PM

Philip,

So… that's very sad to read. Because I can only think of one (1) explanation for software that
creates tagged PDF, and
claims conformance with PDF/UA, but
ONLY emits <P> elements.
That singular explanation is decidedly unflattering.

If possible, please send me an example such file offline so I can see this for myself. If you can share a point of contact I'd appreciate it.

Duff Johnson

PDF Association, CEO
PDF Association, Inc. Executive Director
ISO 32000 & ISO 14289, Project Leader

p +1.617 283 4226
e <EMAIL REMOVED>
w http://www.pdfa.org
l http://www.linkedin.com/in/duffjohnson/

PDF Association · Association for Digital Document Standards e.V.
Landgrafenstr. 14 · 10787 Berlin · Germany
Tel +49 30 4439 0310 Fax: +49 30 3940 5099
District Court: Berlin-Charlottenburg VR 26099 B


> On Apr 8, 2020, at 14:32, Philip Kiff < <EMAIL REMOVED> > wrote:
>
> To be honest, I was actually quite surprised to discover that the Telerik report PDF that we produced passed the PAC tool PDF/UA test cleanly. The Telerik developers must have spent considerable time ensuring that it would meet all the required technical elements. But there are things that the PAC tool can't test, and that's where the file failed.
>
> The most egregious issue was that all content was simply tagged as P. And when I say "all content" I really mean everything. Headings, list items, labels, tables, table data cells ,table heading cells, footers. Everything.
>
> Now, I've seen plenty of files that are just a string of P tags. And depending on the content, and despite the poor tagging, not only can those files sometimes pass accessibility checkers, they may even be acceptable or reasonably usable by most assistive technology users. For example, lots of short memos or letters really are nothing more than a series of undifferentiated paragraphs anyways.
>
> In this case, however, the purpose of these reports is to present tabular data, so spitting out a linearized series of table cells as P's is a clear fail. And then on top of that, the software applied inaccurate "Alternative text" and "Actual text" attributes to each and every P, that had the effect of replacing all the (albeit poorly) structured content with a single inline stream of text with no separation between elements and with the intended text content replaced by seriously incorrect "Actual text" entries.
>
> It was really suprising to see! Normally, you would have to work very hard to create a PDF that was so unusable and yet appeared via automated testing to be perfect. But that machine software can do it in a jiffy!
>
> Criticism aside, though, what I honestly am hoping is that the Telerik software has some sort of undocumented mapping configuration system that our development team is missing. If we could map individual elements in the report to correct tags, then possibly that terrible faux-tagged PDF could miraculously transform into a truly beautiful PDF/UA with just a handful of tweaks. We haven't been able to get details directly from folks at Telerik yet.
>
> Phil.
>
> On 2020-04-08 14:00, Duff Johnson wrote:
>>> But some colleagues are having difficulty matching that promise to reality(!). I couldn't find much documentation on how to control the tagging of the PDF output. Our initial attempts produced files that were woefully inaccessible, though, surprisingly, they still managed to pass the PAC (PDF Accessibility Checker) tool tests cleanly with zero errors.
>> When you say "woefully inaccessible" could you say more? What, in particular, was inaccessible?
>>
>> PAC does the "machine" checks… but validation of tagging semantics is up to the person running the software…
>>
>> Duff.
> > > >