So the demo you're referring to is this one, right?
<a target="_blank" rel="nofollow" href="http://ui.jquery.com/repository/latest/demos/functional/#ui.tabs">http://ui.jquery.com/repository/latest/demos/functional/#ui.tabs</a>
At the moment, Tabs sort of works with the keyboard, due in large part
to the fact that each tab is rendered with a plain old link
underneath. It could be improved with a few tweaks:
1. Switching to the arrow key style interaction. This involves making
the tab container focusable with the "tab" key, and controlling the
selection of each individual tab with the left/right arrow keys.
2. Providing an easy-to-recognize indicator that a particular tab has
keyboard focus.
3. Adding ARIA to it.
I've illustrated how this could be accomplished in the example
Michelle D'Souza pointed out earlier in the thread.
As for your question about the style guide, that's a big one, which
opens an interesting can of worms. I'll see if I can summarize the two
potential options:
1. As per the style guide, a tab should be selected immediately upon
being focused with the arrow key.
2. Tabs should not be automatically selected when they get focus. The
user should be able to explore the list of tabs with the arrow keys,
and then press Enter or Space to select their desired tab.
There are a few factors to consider when choosing one or the other. If
you check out tabs on your desktop OS, you'll find that they behave
differently between the Mac and Windows. Windows uses style #1, while
the Mac more or less uses style #2.
The other issue that you mention is AJAX. If the contents of a tab are
loaded dynamically upon selection, it could be quite tedious for the
user if they have to wait for each tab to load as they cycle through
the list.
Yahoo has written an interesting article about how they implemented
their Tabs widget, and it includes some discussion about these issues:
<a target="_blank" rel="nofollow" href="http://yuiblog.com/blog/2008/07/30/tabview-aria/">http://yuiblog.com/blog/2008/07/30/tabview-aria/</a>
They chose to use style #2. I think that they probably made a good
choice, but I can see both sides of the argument. Alternatively, we
could choose to allow the implementor to configure the style they
prefer, or perhaps switch the behaviour based on detecting what
operating system we're running on.
Thoughts?