Telerik blogs
Build accessibility compliant reports with Telerik Reporting banner title image

Producing accessible reports is essential for businesses that reach out to a wide audience. Telerik Reporting is ready to provide this valuable feature.

In this article, I will write about an often neglected, yet really important component of modern web applications—accessibility. When your business needs to reach a broader audience, it is vital to produce documents that are available for all users. This includes the people with motor control restrictions who experience difficulties working with a mouse or trackball, and the ones that need to use additional assistive technologies like screen readers to interpret the document content.

Fortunately, there are well-known standards and guidelines that specify how to make a document accessible. In the R3 2017 release of our product, we introduced accessibility support for our HTML5-based viewers, following the recommended practices from Section 508 of the Rehabilitation Act and Web Content Accessibility Guidelines (WCAG) 2.0. Now our users can effortlessly add accessible reports to any flavor of web applications that we support, producing content according to standards set by the WAI-ARIA specification. The process involves providing accessibility support for both report viewer and report content.

Accessible Report Viewer

The Report Viewer is the widget that allows users to preview the report and interact with the reporting engine when changing the parameters, browsing through the report pages or navigating in the document map. It now provides an option that switches its accessibility mode on or off. When the accessibility mode is enabled, the viewer activates the keyboard support, starts emitting dynamically generated descriptions for non-text items and instructs the reporting engine to render the reports according to the accessibility standards mentioned above.

Keyboard Support

Every part of the report viewer is dedicated to a different task. Based on that, it can be separated into four main areas:

  • Content—this is the main area where the currently rendered report is displayed
  • Menu—the menu bar that is used to navigate forth and back in history, go to a certain page and execute commands on the rendered report, like printing, exporting, etc.
  • Parameters—the panel where the report parameters (if any) are displayed, so the user can change them and preview the report with the new values
  • Document map—a tree view that reflects the report structure, providing a set of navigational links to the report items in the rendered report

In accessibility mode the viewer labels the areas as landmarks and allows using shortcut keys to directly focus on them and navigate within their content—menu buttons, parameter editors and document map nodes. When a report is rendered in accessibility mode, its content is marked as focusable and can be traversed with the keyboard. The keyboard can also be used to execute an interactive action if the focused report item has one set.

Dynamically Generated Descriptions

When the accessiblity mode is enabled, the focusable elements in the viewer areas provide labels that can be read by an assistive technology like a screen reader.

The menu area sets labels on its buttons and submenus, explaining the function they execute and their current state (enabled or disabled). The parameter area provides information about the parameters it contains, as does each parameter editor about its type, currently selected value and (if needed) a validation message. The document map area generates labels for its nodes so the screen reader can inform the user which navigational link currently has focus.

Accessible Report Content

When designing a report using Visual Studio or Standalone Report Designer, the user can provide additional information about every report item, setting an expression for its AccessibleDescription property. The evaluated expression will produce a WAI-ARIA compliant attributes, but it will be respected only when the report viewer has its accessibility mode enabled, so no redundant markup will be generated. This property is extremely useful when the report contains a non-textual item like a PictureBox or Graph, and helps provide valuable information to the user about the currently focused element.

By default, if the AccessibleDescription value is not set, the report item will produce an accessible label, based on its Value property, which would cover the most scenarios and no report refactoring will be needed. Additionally, the engine concatenates some meta information, related to the current report item, so the user will be given as much detail as possible. 

For example, if the report contains a table, its accessible label will automatically be appended with information about the rows and columns count. Each of the table cells will emit information about its position in the table—whether it is a header cell, and on which row and column it is placed. So if a report contains a TextBox with Value = "Sorts by Category," that performs a sorting action and is nested in a table's first (header) row and third column, the generated label value will be: Text box. Performs a sorting action. Column header. Column two, row zero. Sorts by Category.

Customization

The HTML5-based report viewers accessibility mode is disabled by default, so no excessive HTML markup will be generated. It can be set through the report viewer’s initialization script, using the enableAccessibility(true) option. When adding a report viewer to a project with the Item Template Wizard, its last page suggests setting the accessibility mode and generates the required option automatically. The texts, generated by the accessibility module, can be localized easily, and the default shortcut key mapping can be changed if it interferes with the default browser behavior.

Want to Learn More?

Having a report tool that produces content to meet accessibility standards can be a great benefit when striving to provide the best solution for the most people. The Telerik Reporting team at Progress will continue our efforts to introduce the accessibility support for the entirety of technologies covered by our report viewers. If you would like to learn more about the process, take a look at the new features, check the product roadmap or try it yourself for free!

Get Reporting in our Bundles

You can get Telerik Reporting as an individual product or as a part of our bundles. We bring the best of Telerik and Kendo UI together in convenient bundles, including a wide-range of UI, reporting and productivity tools for both .NET and JavaScript technologies and support that’s got your back in every step of your project. Thanks to our intuitive APIs, alongside thousands of demos with source code availability, comprehensive documentation and a full assortment of VS templates you will get up and running with our tools in no time and fully embrace your inner warrior (Kendoka/Ninja).

By leveraging the broad array of themes, skins, styling and customization options, your application will awe even the best front-end designers. Check it out!


ivan-hristov
About the Author

Ivan Hristov

Ivan Hristov has been a software developer in the Telerik Reporting division since 2013. 

When not at work, he might be seen biking/skiing with his daughter, reading or discussing influential movies with friends. Feel free to reach out to him through LinkedIn.

Related Posts

Comments

Comments are disabled in preview mode.