The menu is currently accessible (in Chrome at least) in the sense that you can click space to open it and then tab to go through the menu items.

If we want to follow the w3c guidelines here a JavaScript solution is the only thing that would work.

This code doesn't quite work but is basically the sort of thing we'd need to do. Hard to say whether at this stage it is worth making this change, or delaying until later though, especially if we have someone who can advise us better on this. It does seem a little risky as our JavaScript could mess up default screen reader behaviour if not done correctly.

 $('.vector-menu-dropdown').on('keydown', (event) => {
  var $menu = $(event.target).closest('.vector-menu');
  var $active = $menu.find('li[tabindex=0]');
  if ( !$active.length) {
     $active = $menu.find('li').eq(0);
  }
  console.log(event.keyCode, event.target);
  switch ( event.keyCode ) {
      case 27: // escape
        $menu.find('input').prop('checked', false);
        break;
      case 38: // up
        $menu.find('li').prop('tabindex', '-1');
// set tab index so that if user tabs away and comes back tab position is  retained.
        $active.prev().prop('tabindex', 0).focus();
        break;
      case 40: // down
        $menu.find('li').prop('tabindex', '-1');
        $active.next().prop('tabindex', 0).focus();
        break;
      default: 
        // return for unsupported key so we don't break tab/enter behaviour.
        return;
  }
  // prevent default for anything that matched.
  event.preventDefault();
} );

I'd suggest shipping that in Vector
https://developer.mozilla.org/en-US/docs/Web/Accessibility/Keyboard-navigable_JavaScript_widgets recommends using keydown event handler (as IE will not fire keypress events for non-alphanumeric keys) as this seems very Vector specific right now.

Related task: https://phabricator.wikimedia.org/T310828

Moving onto board to make the decision on whether this is a deployment blocker. If we decide it is not, we can move back to the backlog for future development

After doing some more research I don't think this work is necessary at the time. The keyboard support recommended by w3 is for "true" menu (in the WAI-ARIA sense), i.e. menus that use role="menu" and role="menuitem" and are for JS driven applications. Our menus are more accurately described as "navigation menu buttons", which contain links ("true" menus shouldn't contain interactive content)

In our case, the most important way our dropdowns are accessible is via tab, so if anything T262872 is more of a priority. I'd recommend probably remain in the backlog unless testing with AFB reveals anything new.

Thanks bernard! Moving back to backlog for now since it's not a deploy blocker.

When I am trying to search something in the search box provided by vector-2022 skin, I found that if you press the Home/End key, it will focus (and search box will be autofilled with) the first/last result. I found this task which said it's a recommended behavior (for menu), but is it also a recommended behavior for inputbox?