In Development
Last Updated: 14 Aug 2019 11:45 by ADMIN
Created on: 08 Nov 2017 17:38
Category: Grid
Type: Feature Request
SHIFT+F10 hotkey should open grid's context menu without bringing up browser's own menus (Accessibility Issue)
For keyboard users who don't have a specific Context Menu key (see, they typically need to use the Windows standard SHIFT+F10 hotkey to trigger a contextmenu event.

For example:

1.	In IE, load
2.	Tab to a column header link
3.	Press SHIFT+F10 (standard Windows/IE hotkey to open context menu)
4.	Notice the context menu displays, however, the focus is really on the IE menubar. IE supports F10 to open the menubar, but is also seeing SHIFT+F10 too.

1.	In FireFox, load
2.	Tab to a column header link
3.	Press SHIFT+F10 (standard Windows/IE hotkey to open context menu) then press down arrow
4.	Notice the context menu displays, however, the focus is really on FireFox's application system menu in the upper left.

Chrome does not have this issue - it opens the grid context menu only.
We need IE and FireFox to also only open the grid's context menu, and not trigger default browser behavior.

According to, it is possible to correct this behavior by calling event.preventDefault() when SHIFT+F10 is pressed, but then trigger a synthetic contextmenu event anyway.

As a workaround, we know users can press Escape to close the browser's default menu and bring focus back into the HTML document (and thus the grid's context menu), but this throws off the user experience and becomes a training issue.
Posted on: 14 Aug 2019 11:45
We just released the Latest Internal Build 2019.2.814 of the suite with a fix for this issue.

You can check the release notes at as well as download the installation from

Progress Telerik
Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers. Learn More.
Peter Milchev
Posted on: 22 Mar 2018 12:06
Hello Kyle, 

Tweaking a bit the gridContextMenu function from the code library achieves the focusing of the ContextMenu and when you close it, with ESC for example, it focuses the Grid

function gridContextMenu(gridEl, event) {
    // some other code here....
    if (event.which == 3) {
        if ($("td").prop("class") == "rgActiveCell rgSelectedCell") {
    else {
        var menuX = $(cell).position().left + $(cell).width() / 2;
        var menuY = $(cell).position().top + $(cell).height() / 2;
        menu.showAt(menuX, menuY);
        // START focus the context menu and refocus grid when hiding 
        var item = menu.get_items().getItem(0);
        menu.add_hidden(function () { gridEl.focus() });
        // END focus the context menu and refocus grid after hiding 
Posted on: 21 Mar 2018 13:36
Am I missing something?  When I run the solution above and press shift+F10, it correctly shows the context menu but you cannot navigate to it by keyboard.  I need this to work for ADA accessibility compliance. Is there a way to reach the menu items that display via keyboard?
Posted on: 25 Dec 2017 15:34
Hi Mike, we've prepared a sample RadGrid web site which demonstrates how this requirement can be achieved in the closest way possible:
Marin Bratanov
Posted on: 09 Nov 2017 15:41
Sorry for not being clear enough. My point is that some users my actually be expecting Shift+f10 to give them the browser menu bar as well as the context menu. I do not have data on the usage of these keyboard combinations.
Posted on: 09 Nov 2017 14:22
I'm not saying to disable the F10 - that would be a problem for keyboard users to get to the browser's menubar/menu.

We need to just handle SHIFT+F10 only (at least on Windows browsers), by preventDefault() and if necessary, trigger a native contextmenu event on the target element so that its menu still opens up.

I haven't tested this on Mac or other platforms, but the YUI article linked talks about some of those needs.
Telerik Admin
Posted on: 09 Nov 2017 11:06
One note on this - F10 focuses the browser menu bar by default and this may be a feature expected by some users. Preventing it from the web page actually affects the way the end user interacts with their OS, not just with the web page.

That being said, if this feature becomes popular, we will consider its implementation.