E-mail List Archives
Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
From: Philip Kiff
Date: Apr 8, 2020 12:32PM
- Next message: Duff Johnson: "Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?"
- Previous message: Danielle Chouhan: "ADA-compliance for abstract reasoning testing"
- Next message in Thread: Duff Johnson: "Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?"
- Previous message in Thread: Duff Johnson: "Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?"
- View all messages in this Thread
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.
- Next message: Duff Johnson: "Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?"
- Previous message: Danielle Chouhan: "ADA-compliance for abstract reasoning testing"
- Next message in Thread: Duff Johnson: "Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?"
- Previous message in Thread: Duff Johnson: "Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?"
- View all messages in this Thread