diff --git a/static/menu.js b/static/menu.js index 87e116a6e..6ad05f9d6 100644 --- a/static/menu.js +++ b/static/menu.js @@ -128,14 +128,47 @@ break; case "enter": case "return": + // enter and return have the default browser behavior, + // but they also close the menu + // this behavior is identical between both the WAI example, and GitHub's + setTimeout(function() { + closeMenu(); + }, 100); + break; case "space": case " ": - // enter, return, and space have the default browser behavior, - // but they also close the menu + // space closes the menu, and activates the current link // this behavior is identical between both the WAI example, and GitHub's + if (document.activeElement instanceof HTMLAnchorElement && !document.activeElement.hasAttribute("aria-haspopup")) { + // It's supposed to copy the behaviour of the WAI Menu Bar + // page, and of GitHub's menus. I've been using these two + // sources to judge what is basically "industry standard" + // behaviour for menu keyboard activity on the web. + // + // On GitHub, here's what I notice: + // + // 1 If you click open a menu, the menu button remains + // focused. If, in this stage, I press space, the menu will + // close. + // + // 2 If I use the arrow keys to focus a menu item, and then + // press space, the menu item will be activated. For + // example, clicking "+", then pressing down, then pressing + // space will open the New Repository page. + // + // Behaviour 1 is why the + // `!document.activeElement.hasAttribute("aria-haspopup")` + // condition is there. It's to make sure the menu-link on + // things like the About dropdown don't get activated. + // Behaviour 2 is why this code is required at all; I want to + // activate the currently highlighted menu item. + document.activeElement.click(); + } setTimeout(function() { closeMenu(); }, 100); + e.preventDefault(); + e.stopPropagation(); break; case "home": case "pageup":