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.
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.
Every part of the report viewer is dedicated to a different task. Based on that, it can be separated into four main areas:
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.
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.
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.
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.
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!
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 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.