[Solved] Kendo Grid Keyboard Navigation Fails

1 Answer 36 Views
Accessibility Grid
Lee
Top achievements
Rank 2
Bronze
Bronze
Bronze
Lee asked on 04 Feb 2026, 07:44 PM | edited on 06 Feb 2026, 11:11 PM

I am trying to implement keyboard only navigation on a web application I am developing to meet accessibility requirements. I am running into problems with the Kendo Grid. 

Here is a dojo: https://dojo.telerik.com/KUcMekCh

I have a grid with 2 locked columns with a button in the first column and a hyperlink in the second column, the other columns just have text. I set navigatable to true. None of my fields are editable.

When the user tabs to the grid, they first get the search bar in my custom grid toolbar. Next they tab to the button (which happens to be a bootstrap dropdown menu but I don't think that is relevant). Here is where the issues start:

  1. They then hit tab again and sometimes are taken to the hyberlink while other times they are taken to the next row, skipping column 2's hyperlink. 
  2. The grid does not always enter Kendo's navigation mode. When it doesn't, there is no way for the user to interact with the column header which has the sort and tooltip buttons in it.
  3. When they get to the bottom of the grid, the locked side will scroll vertically but the unlocked side remains in place, causing the rows to be misaligned.
  4. When an input cell is in the unlocked portion of the table, the user has to tab through the entire list before getting back to editing the input for a row. This isn't logical.
  5. I worry that if there were editable cells, which some of my grids have, the user won't be able to tab to the next editable cell and instead will be forced to navigate through every cell. I don't want to make it more difficult for a normal user in order to accommodate a keyboard only user so there needs to be a way for both to work well.
  6. Often the focus ends up on the unlocked table which attempts to put a blue outline around that, however, the outline isn't fully visible since that is inside of a scrollable div.
  7. You can click into a cell with navigatable set to true and then use the navigation but that doesn't work for a keyboard only user.
  8. When navigatable is not turned on, the user cannot scroll vertically if they tab to the table.

1 Answer, 1 is accepted

Sort by
-1
Nikolay
Telerik team
answered on 09 Feb 2026, 12:08 PM

Hello Lee,

Thank you for providing detailed feedback and the Dojo example. I understand you are aiming for accessible, keyboard-only navigation in your Kendo UI Grid with locked columns and custom cell templates. Here’s a breakdown of the issues you described, explanations, and actionable suggestions:

1. Tab Order Inconsistency (Button/Hyperlink Skipped or Focus Issues)

The Kendo UI Grid's keyboard navigation, when navigatable: true, is cell-based. However, when custom templates include interactive elements (like buttons or links), the browser’s native tab order may interfere, especially if those elements are focusable (e.g., have tabindex="0" or are naturally focusable).

Actionable Solution:

- Ensure that only one element in each cell is focusable. If you have a button or link, set tabindex="-1" for other focusable elements in the same cell.

- Consider managing focus programmatically in your template, so that only the grid cell is focusable and keyboard events (like Enter or Space) trigger the button/link action.

- You can also use the grid’s navigatable: true mode and rely on keyboard events within the cell to trigger actions, rather than tabbing into the interactive elements directly.

2. Grid Navigation Mode Entry and Header Accessibility

The grid enters navigation mode only after a cell is focused (e.g., via mouse click or specific keyboard shortcut). By default, headers (including sort and tooltip buttons) are not included in the grid’s navigation sequence.

Actionable Solution:

- To allow keyboard users to access headers, consider adding custom keyboard shortcuts (e.g., Alt+W as in your code) to focus the grid or header.

- You may need to implement additional logic to allow users to navigate to the header row and interact with sorting/tooltips. This might involve custom scripting to move focus to header elements and handle key events.

- The current grid does not provide built-in keyboard navigation for header actions. If header accessibility is essential, you can submit a feature request for this scenario.

3. Locked Columns and Vertical Misalignment on Scroll

When navigating to the bottom of the grid, the locked and unlocked sections can become misaligned, especially due to differences in scroll handling between the two sections.

Actionable Solution:

- This is a known limitation when using locked columns with scrolling. One workaround is to synchronize the scroll positions programmatically. You can listen for scroll events on the locked and unlocked sections and set their scrollTop values to match.

Example:

var grid = $("#grid").data("kendoGrid");
grid.tbody.closest(".k-grid-content").on("scroll", function() {
  $(".k-grid-content-locked").scrollTop($(this).scrollTop());
});
$(".k-grid-content-locked").on("scroll", function() {
  grid.tbody.closest(".k-grid-content").scrollTop($(this).scrollTop());
});

For more details, see the official documentation on locked columns:

https://docs.telerik.com/kendo-ui/controls/data-management/grid/appearance/columns/locked-columns

4. Tabbing to Inputs in Unlocked Columns

When an input is in the unlocked section, keyboard navigation may require tabbing through all rows before reaching the input, which is inefficient.

Actionable Solution:

- Consider using custom keyboard handling to jump directly to the next input or editable cell. You can listen for keydown events and programmatically set focus to the desired element using jQuery.

- If you want to limit keyboard navigation to certain columns, you can skip non-editable/non-interactive cells in your custom logic.

Example approach:

$("#grid").on("keydown", "td", function(e) {
  if (e.key === "Tab") {
    // Custom logic to focus the next input or editable cell
  }
});

For a related workaround, see:

https://www.telerik.com/forums/navigatable-grid-stops-at-non-editable-cells

5. Editable Cells and Navigation

By default, the grid does not skip non-editable cells during keyboard navigation.

Actionable Solution:

- Implement a custom navigation handler to skip non-editable cells. This requires tracking which columns are editable and updating focus accordingly.

- Example forum thread with community workarounds:

https://www.telerik.com/forums/navigatable-grid-stops-at-non-editable-cells

6. Focus Outline Not Fully Visible

The focus outline may not be visible if the focused element is inside a scrollable div that is partially out of view.

Actionable Solution:

- Ensure that when a cell receives focus, you programmatically scroll it into view using .scrollIntoView() or similar logic.

- You can also adjust CSS to improve the visibility of the outline.

7. Toolbar Keyboard Navigation

If you are using the Kendo UI Toolbar, full keyboard support is already been implemented.

8. Additional Information Needed

To provide a more tailored solution, could you clarify:

  • Which grid features are essential for your accessibility requirements (e.g., header navigation, direct input editing, etc.)?
  • Are you using batch editing, inline editing, or purely read-only grids?
  • Are there specific ARIA or WCAG requirements you must meet?

Summary & Recommendations

  • The current limitations are due to the grid’s default keyboard navigation logic and browser focus behavior with custom templates.
  • For advanced accessibility, you will likely need to implement custom keyboard event handling and focus management.
  • Synchronizing scroll positions and programmatically managing focus will help address most of your concerns.
  • Please share more details about your requirements or specific accessibility standards, and I can provide more targeted code samples or guidance.

Let me know if you would like a sample implementation for any of the above scenarios.

    Regards,
    Nikolay
    Progress Telerik

    Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

    Lee
    Top achievements
    Rank 2
    Bronze
    Bronze
    Bronze
    commented on 09 Feb 2026, 03:06 PM | edited

    These workarounds unfortunately are not going to be acceptable. Regular users need to be able to navigate the grid using the tab key like they expect. They should be tabbed to the various cells with inputs and buttons while skipping cells that do not have interactive elements. It is also required that this be the same for keyboard only users. They should not be tabbing through every cell. In addition, we should not have to arrow to a cell and then press enter and then tab to the required control within the cell and then press enter or start typing. This is too much and not intuitive. 

    For #8, you asked for additional information. In my Dojo, click the decoy button (or anywhere outside the grid). Tab to the grid. Try to press the up and down arrow keys to scroll the grid. Notice that it doesn't scroll. 

    Below is a simple example of a grid I have. The keyboard user needs to be able to sort the columns but not tab through every cell since there is really nothing to interact with in each cell. I also have grids that are very interactive but not every column is interactive. They are similar to the one in my Dojo where there is a button (sometimes a button and a tooltip in the same cell) and one or two columns with inputs. The user, whether keyboard only or not, needs to be able to tab through the interactive cells only so they can quickly fill out the form fields. 

    Nikolay
    Telerik team
    commented on 12 Feb 2026, 01:42 PM

    Hi Lee,

    Thank you for providing further details about your requirements and expectations for an accessible, intuitive tab order in the Kendo UI Grid. I understand that both keyboard-only and regular users need to be able to tab directly to interactive elements such as buttons and inputs, while skipping non-interactive cells, and that the current navigation model is not meeting this need.

    The built-in grid navigation is cell-based, not element-based. This means users must tab through every cell, even if it contains no interactive content. Arrow key navigation only works when the grid is in navigation mode, which is not automatically activated by tabbing into the grid from outside. Additionally, there is no built-in support for keyboard users to sort columns unless custom logic is added. The default behavior requires multiple key presses to interact with elements inside a cell, which is not intuitive or efficient for end-users.

    At this time, achieving the exact tab behavior you described requires custom implementation. Here are the main approaches:

    One approach is to create a custom tab order. You can manually set tabindex="-1" on all non-interactive cells and assign tabindex="0" only to interactive elements such as buttons and inputs. This will allow users to tab directly between interactive elements.

    Another approach involves programmatic focus management. You can attach a keydown event handler to the grid and programmatically move focus to the next interactive element when the Tab key is pressed, effectively bypassing non-interactive cells. An example approach would look like this:

    $("#grid").on("keydown", function(e) {
      if (e.key === "Tab") {
        // Find the next interactive element in the grid
        // Set focus programmatically and prevent default if needed
      }
    });

    For header accessibility, you can add custom keyboard shortcuts such as Alt+S to focus and activate sorting on headers, allowing keyboard users to sort columns.

    Regards,

    Nikolay

     

    Lee
    Top achievements
    Rank 2
    Bronze
    Bronze
    Bronze
    commented on 12 Feb 2026, 01:55 PM

    This is still not a great solution as doing something like alt s would require me adding a note on the screen explaining this and any other custom shortcuts and ensuring that the keyboard user reads it. This also causes a lot of custom amd non intuitive programming, especially when trying to retrofit applications that have already been built. I would like to see a fix in the 2026 Q3 release. 
    Nikolay
    Telerik team
    commented on 17 Feb 2026, 10:29 AM

    Hi Lee,

    Let us take a step back and review the overall behavior.

    Grid navigation is enabled through the navigatable property, which provides predefined keyboard interactions. The Tab key moves focus between the primary Grid elements—the toolbar, table, and footer—but it is not intended for navigating between individual table cells. Cell-to-cell navigation is handled באמצעות the arrow keys.

    The available keyboard shortcuts are documented below the Grid in the official Keyboard Navigation demo:
    https://demos.telerik.com/kendo-ui/grid/keyboard-navigation

    When the Grid is editable and a user tabs through edited cells, it is possible to skip non-editable cells. This behavior is demonstrated in the following Knowledge Base article:

    https://www.telerik.com/kendo-jquery-ui/documentation/knowledge-base/grid-tabkey-navigation-exclude-noneditable-columns

    Column Hyperlinks

    Column hyperlinks are generated using a template. Therefore, you need to explicitly define tabindex attributes within the template where appropriate, depending on whether the elements should participate in sequential keyboard navigation.

    Additionally, I tested the Grid by navigating between cells using the arrow keys and did not observe any misalignment between the locked and non-locked table sections.

    Dojo example:https://dojo.telerik.com/DJmvwyrQ

    Nikolay

     

     

     

    Tags
    Accessibility Grid
    Asked by
    Lee
    Top achievements
    Rank 2
    Bronze
    Bronze
    Bronze
    Answers by
    Nikolay
    Telerik team
    Share this question
    or