Create Accessible PDF Documents with Telerik Reporting

Our latest addition to the accessibility story is enabling the PDF rendering extension to produce PDF files that comply with the PDF/UA standard. 

Whether we are writing code, authoring an article or composing a poem, we usually want to get our message delivered to as many people as possible. Sharing our work with others is getting much easier with the advantages that modern technology gives us. This task gets even more important when the shared information represents business data that needs to be accessed by a broader audience.  

A key factor here is to choose a suitable medium, and Adobe’s PDF file is arguably the best way to spread the message. PDF stands for Portable Document Format and indeed it is a well-established standard for creating and distributing documents, which can be read on virtually any current platform and device. But the PDF standard has one more very important feature – it can produce documents in a way that allows users with disabilities to be able to perceive the shared information. This feature is called accessibility and is defined by the PDF/UA standard which is aimed at production companies of software and assistive technologies. 

Accessible PDF Documents

We on the Telerik Reporting team introduced accessibility support in R3 2017 and have since continued evolving further in this direction. Our latest addition to the accessibility story is enabling the PDF rendering extension to produce PDF files that comply with the PDF/UA standard. The most important characteristics of these files are listed below:

• Tagged contents - all textual items in the report will have a corresponding accessibility entry in the PDF structure. This entry contains the text recognized by the screen readers and other assistive technologies. The rules to generate the text in tagged contents are the same used to generate the metadata in rendered report contents and can be checked here. 
• Description for non-textual items - the PictureBox, Graph and Map items should provide meaningful accessible descriptions as well. This description is persisted in a tagged element with configured actual and alternate text. Other graphical primitives like borders will be treated as non-informational elements and will be added in the PDF document structure as artifacts. 
• Annotations - all the links in the document have a respective link annotation object in the PDF structure. The purpose of the link annotation objects is to provide additional information about the currently selected navigational link. 
• Document Title - the title is obtained from the PDF device information settings that can be set via code or through the configuration file. When unavailable, the DocumentName property of the report will be used instead. 
• Document Natural Language – like the document’s title, the document language should be set in the PDF device information settings. If unavailable, the value of the Culture.Name property of the report will be used instead. 

Configuration 

The setting that determines whether the reporting engine would add the accessibility information to the PDF document is named enableAccessiblity and is passed through the PDF device information settings. The settings can be also controlled from the report viewer’s EnableAccessibility property, providing a consistent behavior between viewed content and exported documents. Since the report viewer setting has a broader scope, it has lower priority than the settings explicitly set in device information object. The accessibility feature can also be enabled in code, for example, when the PDF file is produced from the ReportProcessor class:

var rs = new TypeReportSource() { TypeName = typeof(Dashboard).AssemblyQualifiedName }; 
var deviceInfo = new Hashtable() 
{ 
    { "EnableAccessibility", true } 
}; 
var result = new ReportProcessor().RenderReport("PDF", rs, deviceInfo); 
File.WriteAllBytes("AccessibleDashboard.pdf", result.DocumentBytes);

Results Assessment

The most complete document that describes the checks that a PDF file needs to pass to satisfy PDF/UA standard, is the Matterhorn Protocol. It specifies which of the failure conditions can be tested with dedicated software and which need to be examined manually. Based on this protocol, many tools can evaluate the produced PDF document and determine if it complies to the accessibility standards established with PDF/UA.

For example, Adobe Acrobat provides a thorough test that traverses the PDF structure and its metadata and outputs a detailed report as shown below:

Another comprehensive and free testing tool is PAC - PDF Accessibility Checker. PAC is built in accordance with the Matterhorn protocol and evaluates all the failure conditions that can be tested with a software product. It also includes a screen reader preview that helps to determine how the document will be interpreted by screen-reading applications like NVDA and JAWS, utilized by the visually impaired users. The report that PAC tool displays when checking a PDF/UA compliant file looks like this:

Want to Learn More?

If you are new to our tools or have only tried some, make sure you download the trial and take them for a spin. You can either download just the Reporting and Report Server tools, or download a trial of our entire set of .NET and JavaScript tools with the DevCraft bundle.

We're eager to hear what you think, so please don't forget to share your feedback and help us make Telerik Reporting even better.