[Linux]: Accessibility in CSDK
Summary: The discussion focuses on how to enhance accessibility in Sisense analytics applications using the Compose SDK. Accessibility, also known as a11y, is crucial for users with disabilities and improves usability for everyone. The article explains accessibility standards like WCAG and discusses the integration of Highcharts for accessible charts within Sisense. It emphasizes that while the SDK provides initial support, developers must ensure accessibility through keyboard navigation, focus management, semantic HTML, and proper color contrast. Best practices include testing with tools like Lighthouse and ensuring elements are keyboard-accessible and screen reader-friendly. By following these principles, developers can create inclusive and accessible analytics experiences.
This article explains how accessibility (a11y) is supported in Sisense and how you can build more accessible analytics applications using the Sisense Compose SDK.
Accessibility is not just about supporting users with disabilities. It also improves the experience for keyboard users, users with temporary injuries, older users, and anyone who benefits from a more usable interface.
Compose SDK already provides accessibility support for several built-in components, but building an accessible application is a shared responsibility between the SDK and the developer.
What is Accessibility (a11y)?
Accessibility (often abbreviated as a11y, because there are 11 letters between "A" and "Y") is the practice of building applications that everyone can use, including people with visual, hearing, motor, or cognitive disabilities.
One of the most important accessibility standards is the Web Content Accessibility Guidelines (WCAG), which defines recommendations for making web content more accessible.
Since Compose SDK is used to build web applications, following these guidelines helps ensure your dashboards are usable by as many people as possible.
WCAG defines three levels of conformance:
Level A
The minimum accessibility requirements.
Level AA
The recommended level for most web applications.
This is the level we'll focus on throughout this article.
Level AAA
The highest accessibility level. It includes additional requirements that are often difficult or unnecessary for most business applications.
Accessibility in Sisense Fusion
There are several ways to improve accessibility when using Sisense Fusion.
The Accessibility App is an external plugin created by QBeeQ that provides multiple accessibility settings and customization options.
The Accessibility Button Plugin, created by Paldi, adds a toggle that changes supported visualizations into a more screen-reader-friendly experience.
These are currently the primary accessibility options available for Fusion.
Another important improvement is enabling the New Side Navigation, which already includes better keyboard navigation and accessibility support.
Admin → Feature Management → Management
If you're embedding Fusion dashboards, enabling CSDK Mode can also improve accessibility for navigation and UI interactions.
However, if your goal is to achieve WCAG Level AA, embedding your analytics using Compose SDK generally provides greater flexibility and control over accessibility.
Embedding Analytics
The two most common ways to embed Sisense analytics are: IFrame and Compose SDK.
Using an IFrame is not an accessibility issue by itself. However, the embedded Fusion application must also be accessible, since users are interacting with the Fusion interface.
Compose SDK gives developers much more control over accessibility because the surrounding application is built entirely with React.
Accessibility in Compose SDK
Compose SDK already provides accessibility support for many built-in components, especially charts powered by Highcharts.
However, accessibility is a shared responsibility.
Compose SDK provides:
Built-in accessibility support for Highcharts
Theme customization
Accessible React components
Integration with semantic HTML
Developers are still responsible for:
Building semantic page structures
Keyboard navigation for custom components
Focus management
Color contrast
Labels and descriptions
Accessible custom widgets
Testing accessibility
The following concepts are the foundation of building accessible Compose SDK applications.
Core Accessibility Concepts
Semantic HTML
Semantic HTML is one of the most important accessibility principles. Instead of generic elements like div, use HTML elements that describe their purpose, such as: main, navm section, article, header, footer, button
Semantic HTML helps browsers, screen readers, and assistive technologies understand the structure of your application.
Whenever possible, prefer semantic HTML instead of recreating its behavior with JavaScript.
Keyboard Navigation
Not every user interacts with your application using a mouse.nUsers should be able to navigate your application using only the keyboard. Common keyboard interactions include:
Tab: Move to the next interactive element
Shift + Tab: Move to the previous element
Enter: Activate buttons and links
Space: Activate controls
Arrow Keys: Navigate lists, menus, or tables
Home, End: Jump to the first or last item
Escape: Close dialogs or menus
Proper keyboard navigation is one of the easiest ways to improve accessibility.
Focus Management
Keyboard users always need to know which element currently has focus.
Every interactive component should display a visible focus indicator.
When opening dialogs or modals:
Move focus into the dialog.
Keep keyboard focus inside while it is open.
Return focus to the triggering element when the dialog closes.
Good focus management makes applications significantly easier to navigate.
Screen Readers
Screen readers allow blind and visually impaired users to navigate applications.
They rely on semantic HTML, labels, headings, and descriptions to understand the interface.
Using the correct HTML elements is usually enough for many components, but custom components should also provide meaningful labels and descriptions where necessary.
ARIA
ARIA (Accessible Rich Internet Applications) provides additional information to assistive technologies when semantic HTML alone is not sufficient.
Common ARIA attributes include:
aria-labelaria-labelledbyaria-describedby
As a general rule:
Prefer semantic HTML whenever possible. Use ARIA only when native HTML cannot provide the required accessibility information.
Color Contrast
Users should be able to distinguish text, icons, and interface elements regardless of visual impairments.
Follow the WCAG recommendations for color contrast to ensure your application remains readable.
Also avoid communicating information using color alone.
For example, instead of showing only a red indicator for an error, include an icon or descriptive text as well.
Enabling CSDK Accessibility
Compose SDK uses Highcharts to render most chart visualizations. Highcharts includes built-in accessibility features such as: Keyboard navigation, Screen reader descriptions, Accessible chart labels, Improved chart navigation
These features can be enabled through the SisenseContextProvider.
return (
<SisenseContextProvider
url={connection.url}
token={connection.token}
appConfig={{
accessibilityConfig: {
enabled: true,
},
}}
>
<YourApp />
</SisenseContextProvider>
)
Once enabled, users can navigate supported charts using only the keyboard.
This configuration also applies to the DashboardById component, but only for widgets rendered using Highcharts.
Pivot and Indicator widgets use different rendering implementations, so this configuration does not affect them.
Accessibility for Custom Components
When building your own React components, accessibility becomes entirely your responsibility. For example, you can implement keyboard navigation inside a custom table:
function handleRowKeyDown(
e: React.KeyboardEvent<HTMLTableRowElement>,
index: number
) {
switch (e.key) {
case "ArrowDown":
e.preventDefault()
focusRow(index + 1)
break
case "ArrowUp":
e.preventDefault()
focusRow(index - 1)
break
case "Home":
e.preventDefault()
focusRow(0)
break
case "End":
e.preventDefault()
focusRow(data.length - 1)
break
}
}
React makes it straightforward to implement accessible keyboard interactions for custom components.
Color Contrast and Themes
Compose SDK themes allow you to customize colors across your application.
Creating a theme with WCAG compliant color helps improve readability and accessibility throughout your application.
If you're using DashboardById, the situation is slightly different. DashboardById inherits the theme configured for that dashboard inside Fusion.
For Compose SDK widgets rendered with Highcharts, you can also use onBeforeRender to apply additional Highcharts accessibility configurations before rendering.
<ColumnChart
...
onBeforeRender={(highchartsOptions) => {
highchartsOptions.title = { text: "Revenue by country" }
highchartsOptions.accessibility = {
...highchartsOptions.accessibility,
description:
"Bar chart showing total revenue for each country, filtered by the current report options.",
point: {
...highchartsOptions.accessibility?.point,
descriptionFormatter: (point) => `${point.category}: revenue of ${point.y}`,
},
}
return highchartsOptions
}}
/>
highchartsOptions.title: adds the title in the chart.highchartsOptions.accessibility: here we're spreading the a11y object, so we can keep the Highcharts config, and add anything that we want.description: it's not visible in the screen, but help the screen reader.point: we also are keeping the default using spread, but we're putting a description for each data point in the chart.
You can see more about this configs inside Highcharts A11y Module Documentation.
Testing Accessibility
After implementing accessibility improvements, it's important to verify that everything works correctly.
One of useful tool is: Lighthouse.
**You should also test your application using only the keyboard to ensure users can complete every task without using a mouse.
Summary of the Best Practices
Prefer semantic HTML over ARIA whenever possible.
Ensure every interactive element is keyboard accessible.
Always provide a visible focus indicator.
Maintain sufficient color contrast.
Don't rely only on color to communicate information.
Add meaningful labels to custom controls.
Test using both automated tools and screen readers.
Test your application using only the keyboard.
Conclusion
Accessibility is not a feature that can simply be enabled with a configuration option.
Building accessible analytics experiences requires combining semantic HTML, keyboard navigation, focus management, screen reader support, sufficient color contrast, and accessible custom components.
Compose SDK provides many of the building blocks needed to create accessible applications, but achieving WCAG compliance ultimately depends on how your application is designed and implemented.
By following these best practices, you can build dashboards that are more inclusive, easier to use, and accessible to a much wider audience.
You can also access the demo through this url. And the repository in Github.
References/Related Content
Disclaimer: This post outlines a potential custom workaround for a specific use case or provides instructions regarding a specific task. The solution may not work in all scenarios or Sisense versions, so we strongly recommend testing it in your environment before deployment. If you need further assistance with this, please let us know.
