E-mail List Archives
Thread: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
Number of posts in this thread: 8 (In chronological order)
From: Philip Kiff
Date: Wed, Apr 08 2020 8:14AM
Subject: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
No previous message | Next message →
I included the wrong link to the blog post I referenced. Here is the
correct one.
Create Accessible PDF Documents with Telerik Reporting:
https://www.telerik.com/blogs/create-accessible-pdf-documents-with-telerik-reporting
On 2020-04-08 10:10, Philip Kiff wrote:
> Does anyone have experience producing accessible PDF files from
> Telerik .NET Reporting software?:
> https://www.telerik.com/products/reporting.aspx
>
> According to a company blog post from May 29, 2019, Telerik can
> produce a PDF/UA compliant PDF.
>
> Create Accessible PDF Documents with Telerik Reporting:
> https://www.telerik.com/products/reporting.aspx
>
> 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.
>
> Any insight or links to resources would be appreciated.
>
> Phil.
>
> Philip Kiff
> D4K Communications
>
> > > >
From: Philip Kiff
Date: Wed, Apr 08 2020 8:10AM
Subject: Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
← Previous message | Next message →
Does anyone have experience producing accessible PDF files from Telerik
.NET Reporting software?:
https://www.telerik.com/products/reporting.aspx
According to a company blog post from May 29, 2019, Telerik can produce
a PDF/UA compliant PDF.
Create Accessible PDF Documents with Telerik Reporting:
https://www.telerik.com/products/reporting.aspx
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.
Any insight or links to resources would be appreciated.
Phil.
Philip Kiff
D4K Communications
From: Duff Johnson
Date: Wed, Apr 08 2020 12:00PM
Subject: Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
← Previous message | Next message →
> 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.
From: Philip Kiff
Date: Wed, Apr 08 2020 12:32PM
Subject: Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
← Previous message | Next message →
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.
From: Duff Johnson
Date: Wed, Apr 08 2020 12:53PM
Subject: Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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.
> > > >
From: Philip Kiff
Date: Wed, Apr 08 2020 1:11PM
Subject: Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
← Previous message | Next message →
Ha, yes, I was thinking along the same lines, Duff!
But it is perhaps a bit unfair to Telerik and certainly too early yet to
draw such a conclusion. Our team is still learning to use the reporting
tool, and it is definitely possible that our current PDF issues are
simply the result of what one might call "user error"(!).
And unfortunately, due to security and privacy policies, neither the
data nor anything related to the project are shareable, even off-list,
at this time.
But if I am able, I will try to remember to post back to the list in the
coming month or two with at least some general conclusions about the
software, based on whatever we learn.
Phil.
On 2020-04-08 14:53, Duff Johnson wrote:
> 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 ADDRESS 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 ADDRESS 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.
>> >> >> >> >
> > > >
From: Dona Patrick
Date: Wed, Apr 08 2020 3:22PM
Subject: Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
← Previous message | Next message →
Not the same source, but I was sent a PDF to test for compliance that was
created "on the fly" and it passed PAC 3's test, yet it wasn't tagged at
all. Apparently the software creating it was able to add all appropriate
document properties and the PDF/UA metadata, then the content was basically
scanned.
The folks I talked to are open to suggestions. I sent them what they needed
as far as tags, but I am not a software developer.
Dona
On Wed, Apr 8, 2020, 3:11 PM Philip Kiff < = EMAIL ADDRESS REMOVED = > wrote:
> Ha, yes, I was thinking along the same lines, Duff!
>
> But it is perhaps a bit unfair to Telerik and certainly too early yet to
> draw such a conclusion. Our team is still learning to use the reporting
> tool, and it is definitely possible that our current PDF issues are
> simply the result of what one might call "user error"(!).
>
> And unfortunately, due to security and privacy policies, neither the
> data nor anything related to the project are shareable, even off-list,
> at this time.
>
> But if I am able, I will try to remember to post back to the list in the
> coming month or two with at least some general conclusions about the
> software, based on whatever we learn.
>
> Phil.
>
> On 2020-04-08 14:53, Duff Johnson wrote:
> > 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 ADDRESS 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 ADDRESS 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.
> >> > >> > >> > >> > >
> > > > > > > > > > > > >
From: Duff Johnson
Date: Wed, Apr 08 2020 3:46PM
Subject: Re: Telerik .NET Reporting - Accessible PDF Output - How Control Tagging? Links to Resources?
← Previous message | No next message
Sighâ¦
This would also be interesting to see, if an example may be shared. Contact details for the developers would also be welcome.
Duff.
> On Apr 8, 2020, at 17:22, Dona Patrick < = EMAIL ADDRESS REMOVED = > wrote:
>
> Not the same source, but I was sent a PDF to test for compliance that was
> created "on the fly" and it passed PAC 3's test, yet it wasn't tagged at
> all. Apparently the software creating it was able to add all appropriate
> document properties and the PDF/UA metadata, then the content was basically
> scanned.
>
> The folks I talked to are open to suggestions. I sent them what they needed
> as far as tags, but I am not a software developer.
>
> Dona
>
> On Wed, Apr 8, 2020, 3:11 PM Philip Kiff < = EMAIL ADDRESS REMOVED = > wrote:
>
>> Ha, yes, I was thinking along the same lines, Duff!
>>
>> But it is perhaps a bit unfair to Telerik and certainly too early yet to
>> draw such a conclusion. Our team is still learning to use the reporting
>> tool, and it is definitely possible that our current PDF issues are
>> simply the result of what one might call "user error"(!).
>>
>> And unfortunately, due to security and privacy policies, neither the
>> data nor anything related to the project are shareable, even off-list,
>> at this time.
>>
>> But if I am able, I will try to remember to post back to the list in the
>> coming month or two with at least some general conclusions about the
>> software, based on whatever we learn.
>>
>> Phil.
>>
>> On 2020-04-08 14:53, Duff Johnson wrote:
>>> 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 ADDRESS 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 ADDRESS 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.
>>>> >>>> >>>> >>>> >>>
>>> >>> >>> >>> >> >> >> >> >>
> > > >