Accessibility in the Bryntum Grid

Accessibility is an important consideration when integrating web components, including data grids, into your apps. Poor accessibility in your data grid can make your app difficult to use for those with disabilities or temporary limitations, like a broken arm. Additionally, keyboard accessibility benefits users who prefer navigating with a keyboard rather than a mouse. In many cases, ensuring accessibility isn’t just beneficial – it’s required by law.

Making a data grid accessible is time-consuming. The Bryntum Grid has built-in accessibility features that streamline this process. This guide examines how well the Bryntum Grid supports accessibility and how it compares to other popular data grids such as AG Grid, Syncfusion, and DHTMLX.

Web accessibility guidelines and ARIA

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.
• The Accessible Rich Internet Applications Suite (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 includes keyboard accessibility and ARIA roles.

Assessing 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.

Keyboard accessibility in 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 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:

Comparison of keyboard accessibility in data grids

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

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

The Bryntum Grid consistently outperformed alternatives in key accessibility aspects. More accessibility out-of-the-box 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 provided the best keyboard grid navigation, followed closely by AG Grid and Syncfusion. In the DHTMLX tree grid demo, you cannot navigate across a row using the arrow keys and must use Tab instead.

Grid cell navigation

In our evaluation of navigating within a grid cell, Bryntum Grid again demonstrated the best accessibility.

Both the Syncfusion and DHTMLX grids failed the basic keyboard accessibility test due to keyboard traps.

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.

The DHTMLX accessibility support guide claims that all DHTMLX UI widgets meet the main requirements of the WCAG 2.0 standard, including keyboard navigation. While the demo featured in the accessibility support guide passes the basic keyboard accessibility test, the DHTMLX tree grid demo fails the test. As in the Syncfusion Grid, pressing Enter on a cell with an input fails to focus on the input, and the focus styling is lost.

Customizing keyboard shortcuts for improved accessibility

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, as this 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.

ARIA and screen reader support in Bryntum Grid

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. Since it uses div elements instead of native table elements, ARIA attributes are necessary to ensure that screen readers interpret the grid correctly. Many data grids, such as Bryntum Grid, AG Grid, and DHTMLX Grid, use a div instead of a table element for more flexibility when creating complex grids.

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:

Basic ARIA compliance test

We used the Accessibility Insights for Web Chrome extension’s FastPass tests to evaluate the ARIA implementation in the Bryntum Grid and competing grids. FastPass helps identify common, high-impact accessibility issues.

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 ❌:

These are fairly minor issues, and 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. The Bryntum Grid’s keyboard accessibility is excellent, 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

The Bryntum Grid offers best-in-class keyboard accessibility, ensuring compliance with accessibility standards while requiring minimal customization. By integrating accessibility best practices into your development process, you can ensure that your grid is usable for everyone, regardless of ability.

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.