An accessible menu and an operational menu are not mutually exclusive. Accessibility isn't tacked on after the fact. It's part of the DNA of the interface. If you are implementing a true menu (as opposed to a list of navigational elements, which are sometimes referred to as "menus" but they're not really application menus), then having the menu as one tab stop is the expected operation, and arrowing left/right to move to the next menu item is the expected operation. That behavior has been around since the 1980's.
Think of old school applications that had File, Edit, View, etc along the top of the application. Using the alt key (on a PC), I could move my keyboard focus to the menu. I could then arrow left/right to move to Edit, View, whatever. I could not tab to the other menu items.
If you use
role="menuitem" when you implement your menu, the screen reader will announce that these items are menus and the user will expect to be able to use the arrow keys to navigate. The tab key will not be expected to navigate.
There should never be a disconnect between "standard functionality" and "accessible functionality". They are the same.
Now, regarding further details for a menu, see the
menu role. In particular:
To be keyboard accessible, authors SHOULD manage focus of descendants for all instances of this role, as described in Managing Focus.
(their emphasis, not mine)
By "managing focus", they mean to allow the arrow keys to move the focus to the next menu item rather than using the tab key. (You don't have to "manage" the focus yourself when using the tab key. The browser does it for you.)