How accessible are JavaScript data grids?

Accessibility is an important consideration when integrating web components, including data grids, into your apps. Poor accessibility can make your app difficult or impossible to use for people with disabilities or temporary limitations, like a broken arm. Keyboard accessibility also benefits users who prefer navigating without a mouse. In many cases, ensuring accessibility isn’t just good practice; it’s a legal requirement, whether under the Americans with Disabilities Act (ADA), Section 508 of the Rehabilitation Act, or regional equivalents.

Making a data grid accessible from scratch is time-consuming, so you want to begin with a grid that has strong built-in accessibility support, like Bryntum Grid. To help you choose, we examine how well Bryntum Grid supports WCAG compliance and keyboard accessibility, and how it compares to two other popular alternatives, Syncfusion and DHTMLX. We also outline the key accessibility guidelines for data grids, explain how to assess whether your app meets those guidelines, and walk you through conducting basic compliance tests.

WCAG and WAI-ARIA: Web accessibility guidelines for data grids

The World Wide Web Consortium (W3C) develops standards and guidelines for accessibility. These include:

• The Web Content Accessibility Guidelines (WCAG): A set of recommendations for making web content accessible to people with disabilities. WCAG 2.0 Level AA is the widely recognized benchmark for accessibility compliance. It also satisfies ADA and Section 508 requirements, meaning a single standard covers most legal obligations you’re likely to encounter.
• The Web Accessibility Initiative’s Accessible Rich Internet Applications Suite (WAI-ARIA): A set of technical standards that improve accessibility for interactive, dynamic, and complex content, including data grids.

ARIA provides roles and attributes that help assistive technologies interpret web content. For example, ARIA can make custom JavaScript widgets, live content updates, and other dynamic elements accessible.

It’s important to implement ARIA correctly. Bad ARIA is worse than no ARIA at all. Poorly implemented ARIA can negatively impact accessibility. The Bryntum Grid follows best practices for accessibility, which include keyboard accessibility and ARIA roles.

How to assess accessibility compliance

Accessibility should be assessed early and throughout development. While there are tools to help with evaluations, no single tool can fully verify accessibility. Automated tools can produce false positives, particularly with complex and dynamic components like data grids. For example, basic static HTML accessibility checkers may flag issues with dynamically rendered elements that aren’t actually problems. It’s best not to rely solely on accessibility tools, as they are meant to assist with accessibility evaluation, not replace it. The W3C provides a guide to selecting web accessibility evaluation tools to help developers choose the best tools for their needs. To verify accessibility, developers should combine automated tools, manual testing, and real user testing.

If a product or website claims to offer 100% accessibility compliance, be wary. Some WCAG success criteria are open to interpretation, and accessibility testing often examines only a small sample of website content and user environments due to practical limitations. Besides, accessibility testing is not a one-time effort; it needs to be conducted regularly, as website updates can introduce new accessibility issues.

The importance of keyboard navigation in JavaScript data grids

The WCAG outlines four guiding principles that web content must meet to be considered accessible:

Content must be perceivable, operable, understandable, and robust.

Keyboard accessibility falls under the operable category and is defined in WCAG Guideline 2.1. This guideline specifies that all data grid functionality should be accessible via keyboard and that users should not encounter keyboard traps. A keyboard trap occurs when a user navigating by keyboard becomes “stuck” on a particular element and cannot move focus to other parts of the interface or back to where they came from.

Expected keyboard behavior

Data grids should follow the expected keyboard interactions defined by ARIA. These include:

• Navigating the grid using arrow keys.
• Activating interactive elements within cells using Enter or Space.
• Using Page Up, Page Down, Home, End, and modifier keys for efficient navigation.

The Bryntum Grid adheres to these conventions.

Grid navigation, cell editing, and cell menus in the Bryntum Grid

When you navigate using your keyboard to a Bryntum Grid cell with interactive content, such as a button or an input, focus is automatically moved into the cell. You can see this in our column types demo. Navigating to a cell in the Link column automatically focuses on the link, which you can open by pressing Enter:

If there are multiple interactive elements in the cell, you can use the Tab key to move between the elements within the cell. If the elements inside the cell don’t use arrow keys, you can use the arrow keys to navigate to adjacent cells. If the elements use arrow keys, such as a range input, you need to press the Escape or the F2 key to move the focus back to the cell. You can then use the arrow keys to navigate to other cells.

Our widget column demo shows this navigation behavior:

Bryntum Grid text, number, and date columns have a default editor that uses the CellEdit feature. This feature allows editing cells that aren’t interactive by default. To edit the value in a cell with this feature, focus on the cell and then press Enter. This inserts an input field into the cell that allows you to change its value.

The Bryntum Grid also has a CellMenu feature that’s enabled by default. You can open it by right-clicking on a cell or by pressing the Space key when a cell is focused. The cell menu shows four items by default: Delete, Copy, Cut, and Paste.

Comparing keyboard navigation and WCAG compliance across data grids

We compared the keyboard accessibility of Bryntum Grid with other popular alternatives using the following demo grids:

• Bryntum: Grouping demo
• Syncfusion: Ensuring accessibility demo and custom shortcut keys accessibility demo
• DHTMLX: Accessibility support guide demo and tree grid demo

Bryntum Grid performs well across key accessibility aspects, offering strong accessibility out of the box. More built-in accessibility means less custom code or configuration, which saves you time.

Grid navigation

We evaluated how well demos of each grid support keyboard grid navigation.

Bryntum Grid provides the best keyboard grid navigation, followed by Syncfusion, as its ensuring accessibility demo meets all the grid navigation criteria. DHTMLX supports arrow key navigation, but still lacks support for Page Down, Page Up, Ctrl + Home, Ctrl + End, and column sorting. Arrow key support also varies between demos; the accessibility support guide demo supports it, but the tree grid demo requires using Tab to navigate across rows instead.

Grid cell navigation

We also evaluated how well each grid supports navigating within a cell.

DHTMLX fails the basic keyboard accessibility test due to a keyboard trap. Neither of the DHTMLX demos allows you to move focus out of a cell using Tab or Shift + Tab.

In the Syncfusion Grid custom shortcut keys accessibility demo, pressing Enter on a cell with an input fails to focus the input. Additionally, it’s unclear how to select a row for editing with the Edit button using a keyboard. The Syncfusion Grid ensuring accessibility demo has the same issue with Enter, but you can use F2 instead.

The DHTMLX accessibility support guide claims that all DHTMLX UI widgets meet the main requirements of the WCAG 2.0 standard, including keyboard navigation. The tree grid demo contradicts this, as it fails the keyboard trap test.

Improving accessibility with custom keyboard shortcuts

Advanced functionality in an app may conflict with keyboard accessibility, so some accessibility choices need to be made by the developer. For example, the Bryntum Grid doesn’t set Ctrl + A as the default shortcut for selecting all rows, because that shortcut may be used for other functionality in your app.

You can use the Bryntum Grid keyMap config to customize keyboard shortcuts for improved accessibility, such as setting Ctrl + A to select all rows:

const grid = new Grid({
    keyMap: {
        'Ctrl+A': 'selectAll'
    },
});

Add this custom shortcut to our grouping demo using the built-in code editor to see it in action:

Take a look at our guide to customizing keyboard shortcuts to learn how to create your own, including multi-action shortcuts and custom actions.

Ensuring screen reader compatibility with ARIA roles

ARIA is critical for complex data grids to describe non-semantic HTML elements so that they can be understood by assistive technologies such as screen readers. The Bryntum Grid follows the W3C ARIA guidelines for grids, using appropriate roles for cells, rows, and headers. The Bryntum Grid uses div elements instead of native table elements, making ARIA attributes necessary to ensure that screen readers interpret the grid correctly. This is a common pattern among complex data grids, including DHTMLX, as div-based layouts offer more flexibility for features like row virtualization and custom cell rendering.

It’s worth testing with the screen readers most commonly used by your target audience, as screen readers can interpret WCAG differently.

A good way to start assessing your grid’s ARIA compliance is to use the Chrome DevTools Accessibility Tab to view the grid’s accessibility tree, ARIA attributes, and the computed accessibility properties of DOM nodes:

Conducting a basic ARIA compliance test

We used the Accessibility Insights for Web Chrome extension’s FastPass tests to evaluate the ARIA implementation in the four JavaScript data grids. FastPass helps identify common, high-impact accessibility issues and is a useful indicator of WCAG 2.0 Level AA and Section 508 compliance.

To run the check, install the extension in Chrome or the new Microsoft Edge. When you open the extension, you’ll see the Launch Pad where you can select the FastPass tests:

The FastPass tests found the following ARIA issues in the grids, indicated by ❌:

The remaining issues are minor. Syncfusion fails aria-valid-attr-value. Accessibility Insights provides suggestions for how to resolve them.

Remember that keyboard accessibility isn’t a simple pass-or-fail checkbox exercise. It requires understanding how users interact with your app. Bryntum Grid has excellent keyboard accessibility, but you may need to customize it to meet your specific needs.

The FastPass tests are a good starting point for identifying potential issues, but they don’t cover all aspects of accessibility.

Next steps

To further improve accessibility, you can:

• Use screen readers such as NVDA, JAWS, or VoiceOver to manually test screen reader accessibility.
• Perform more comprehensive assessments with Accessibility Insights’ Quick Assess and Assessment tools that also evaluate color contrast, landmarks, images, repetition, errors, and statuses.

Takeaway

Bryntum Grid offers strong accessibility out of the box. Our accessibility documentation is also worth reviewing for more information. By integrating accessibility best practices into your development process, you can ensure that your grid is usable for everyone, regardless of ability.