I found a weird issue during a recent accessibility audit. I was testing a slideshow using the NVDA screen reader and keyboard navigation. The slideshow uses tab controls for the controls to switch the slides (incorrect IMO, but that's a different topic).
The problem was that when my keyboard focus was on the currently selected tab/slideshow control, I couldn't use up and down arrow keys to navigate to the previous and next elements. Instead, those keys scrolled the page, as if I wasn't using the screen reader.
Up and down arrows are standard NVDA (and JAWS, and maybe other SRs I'm not aware of) navigation, so I marked it as a failure of Success Criterion 2.1.1 Keyboard.
But then I decided to dig into exactly why it was happening. I tested the WAI Automatic Activation and Manual Activation tabs examples, which exhibited the exact same behaviour.
In fact, it is more extensive than I first realized. No NVDA keyboard shortcuts work when focus is on an active tab. You have to press the Escape key to break out and resume keyboard navigation, other than tabbing.
I also tested Heydon Pickering's tabs example, which doesn't exhibit this behaviour. His script programmatically hijacks the down arrow keypress from the selected tab to take focus to the current tab panel, rather than the next tab control, but the up arrow works to navigate to the previous element from the active tab, ditto for other NVDA keystrokes.
I did some fiddling with the code of all these examples to try to narrow down the problem. The issue appears to be that buttons given the tab role directly prevent NVDA keyboard navigation when focused. Links with the tab role don't (though I would say it's incorrect to use links), nor do buttons which are given the tab role programmatically rather than directly.
I guess it's possible that this is the intended behaviour. For example, with radio button groups, once you're focused on a button in the group, up and down arrow keys move focus only among the buttons in the group, and other NVDA keyboard shortcuts don't work. You have to press the Escape key to break out of the group and resume keyboard navigation (other than Tab).
With tabs however, up and down keys don't do anything at all, nor can you use the down arrow to navigate to tabpanel content, which seems to me to be a serious problem. Nothing happens, other than page scroll. There's no screen reader feedback, and virtual focus goes nowhere. So I don't think it's a desirable behaviour.
Further testing, and with a wider variety of screen readers, browsers, etc., would be necessary to really define the problem, but for now, my practical takeaway is that when I create tabs, I'll assign the tab role programmatically rather than putting it on the tab buttons directly in code. That's what I've been doing anyway; in fact, I use a modified version of Heydon Pickering's code, but it's good to know about this problem.
It's also a great example of why you can't take WAI, or any other code examples, as absolute gospel. They're a great starting point, especially if you know little or nothing about accessibility, but they're not perfect.