This specific customer is one of the biggest companies that provide cloud-based solutions for human resources and financial management. Their applications are widely used by large companies, including many Fortune 500 organizations, and by leveraging AI to automate common tasks, they help businesses make better decisions.

As an application gets bigger, one important aspect of its existence is the data it collects. It has become one of the most important aspects of any application to gather as much data: personal, usage, browser, location, tracking, and security information. This information is then useful when optimizing any aspect of the business and the application.

Handling the entire amount of information is usually accomplished with applications featuring that have different presentation engines that can aid in help with understanding and analyzing that data. Our customer has dedicated an entire core module for this, creating a data analysis module capable of assisting in managing various data sources.

When talking about any digital application, especially those that are used by millions of people, accessibility is crucial, because it ensures the software can be properly used and understood by as many people as possible, regardless of their abilities or disabilities. There are multiple reasons why A11y is an important factor to consider when developing the application: inclusive user base, support for assistive technology, corporate social responsibility, improved data interpretation, global reach and market expansion, enhanced user experience, and last but not least compliance with regulations.

By prioritizing A11y in any application, organizations can create a better digital environment for all users by creating better UX that is easier to understand and use, enhancing the functionality they provide. Having an analytics application that provides better accessibility support can easily edge over competitors.

When talking about large-scale applications, that don’t yet have enhanced accessibility support, several factors need to be considered for A11y: what are the changes that we need to do, how do we create a “standard” for a11y going forward, how long it will take, and most important, where do we start?

Two big areas are important when discussing A11y: following proper Web Content Accessibility Guidelines (WCAG) guidelines when developing the web application, and creating a UX that is easily accessible.

To have a good starting point, the easiest way would be to get a proper accessibility assessment of the application. When doing a proper accessibility audit using specific tools (like Lighthouse, Axe, or WAVE) we can identify some issues coming from contrast, keyboard navigation, and accessibility standards like proper document structure and semantic HTML elements (as defined by WCAG). Organizing these found issues into several epics, can become the starting point and basis for accessibility compliance.

When we joined our customers' accessibility team, we started with such a backlog and worked our way up to the most important functionalities.

After the initial assessment, most of the issues existing in the analytics engine were based on the A11y principles. Here are some of the categories that we solved:

These are the categories most of the issues we fixed belonged to, but others also could require attention: meaningful link text, focus styles, and language declaration.

All the above issues are usually solved inside the codebase alone. By using the proper HTML tags and adding the proper attributes, assistive technologies can understand the functionality and present it back to users. Since these are done at the HTML level, it’s not dependent on any frontend library that’s used. In our case, since React was the main framework in the core analytics module, we started working our way up from the basic reusable components to the bigger ones.

When talking about specific data analytics functionality, there are several major obstacles. Considering the building blocks of the analytics engine (dashboards, tables, charts, etc), making a properly accessible interface becomes a more challenging task.

For Dashboards, it’s easy to imagine an interface where you can use drag and drop for various actions. Adding, repositioning or even resizing the elements can easily be achieved by using the mouse. However, these types of actions require further development to be achieved by using the keyboard alone. By properly using attributes (ARIA states like aria-selected) and adding visual handles for the functionality, we can describe the widgets in a way that assistive technologies can interpret them.

The elements that are multimedia-based, like charts, require a different type of approach when developing them, to be accessible. The most important factors that come into play are keyboard navigation and text description. When considering charts, one example would be that the legend items need to be accessible using the keyboard and that the chart responds to those selections by highlighting those legend items. By properly using the aria-live attribute, you can add a proper text description of what’s going on in the chart, so that a user who has a visual deficiency can understand its content.

Table elements are the workhorse of any analytics module, but they have some important limitations once they get complicated. When using simple tables, the accessibility support for them is good in multiple screen readers. If properly identified using proper tags (like th) and attributes, navigation over the table cells using NVDA for example, is smooth and the data description is properly handled according to the headers, descriptions, and such attributes.

However, things get a bit more complicated when moving to more complex scenarios. For example, if you’re trying to properly present a Pivot table, having multiple column and row headers that apply to a single cell will not properly work with multiple screen readers (NVDA, MacOS Voice Over, etc). In scenarios like this, it’s usually down to deciding on how you simplify the table itself or create additional presenting ways. For example, one could display multiple tables or use a drill-down approach that would require more interaction to reach the desired results.

Most issues that are found by running an accessibility audit are based on the WCAG guidelines. It’s an analysis of the HTML code that your application has, without considering the UX side of the application. This is usually part of a larger discussion that involves multiple departments that have the shared responsibility and goal to improve the UI/UX of the application with A11y in mind as well.

That’s why, when we started working into the A11y backlog that our customers had, we always paid attention to how we could also improve the existing flows and UI to make it easier to use and understand. By suggesting simplified interactions with the application that can be done with either the mouse or the keyboard, it became easier and more intuitive for the user to use it.

As always, following proper documentation and standards is the best way to add a proper A11y layer over any web application. Resources like the WCAG guidelines, the MDN Accessibility documentation, and the ARIA Authoring Practices Guide are good starting points.

Some of the most used tools for accessibility testing and auditing are Lighthouse, WAVE, and AXE. These provide good insight on how the code should be structured and what are some of the guidelines that need to be followed.

There are multiple options for the screen readers, but the ones we focused on were NVDA and MacOS Screen Reader. These provide a good baseline for interacting with screen readers.