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: Tree grid demo, tested against the Grid accessibility guide

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. Row sorting refers to reordering rows using the keyboard.

Bryntum Grid provides the best keyboard grid navigation. The Syncfusion ensuring accessibility demo and the DHTMLX tree grid demo meet all the grid navigation criteria except row sorting. DHTMLX supports Page Up, Page Down, Ctrl + Home, and Ctrl + End, as well as column sorting by pressing Enter or Space on a header cell and multi-column sorting with Shift + Enter. The DHTMLX Grid accessibility guide lists the full set of shortcuts for the grid header, body, and footer.

Bryntum Grid reorders rows from the keyboard out of the box. The RowCopyPaste feature, enabled by default, lets you cut a row with Ctrl + X and paste it at the focused row with Ctrl + V. DHTMLX Grid has no built-in equivalent. You can reorder rows by handling keydown on the grid container and moving the record with the data.move() method, but this requires custom code.

DHTMLX features such as selection and keyboard navigation are optional modules that you enable in the grid config. Keyboard navigation is enabled by default, but you need to set the selection and editable properties to enable all the available shortcut keys. If you disable selection to show a read-only view, the grid requires Tab to move across rows instead of the arrow keys. Setting selection: "complex" enables full arrow-key navigation in tree grid mode, including expanding and collapsing branches with the arrow keys.

Grid cell navigation#

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

Bryntum Grid and DHTMLX Grid passed the keyboard trap test. DHTMLX Grid matches Bryntum Grid on cell navigation and trails only on row sorting.

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 states that all DHTMLX UI widgets meet the main requirements of the WCAG 2.0 standard, including keyboard navigation, and the DHTMLX release notes describe the grid’s accessibility layer as WCAG 2.2 compliant.

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.

DHTMLX Grid handles custom shortcuts through events rather than a keymap config. Its beforeKeyDown and afterKeyDown events receive the native keyboard event, so you can add a shortcut such as Ctrl + A there. Returning false from beforeKeyDown blocks the default shortcut.

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 three 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 and DHTMLX both fail aria-required-children. The Syncfusion grid element contains its group drop area, toolbar, pager, and clipboard textarea as direct children, and the DHTMLX treegrid element contains its Enter grid and Exit grid focus sentinel buttons. The checkboxes in the DHTMLX boolean column also have no accessible label. FastPass also flagged color-contrast in the Bryntum grouping demo, where the custom Color column renders white text on lime and green backgrounds. 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.