Just wanted to add that truly conventional, accessible tab interfaces have a specific way of handling keyboard operation: Only the left and right arrow keys should switch tabs and – simultaneously – reveal the associated panel. The TAB key is preserved for moving between the active TAB and the open panel. This means inactive tabs should have tabindex=”-1” and be focused/activated only programmatically (via the aforementioned arrow keys).
The reason for this is that keyboard and AT users should be afforded a direct route to the chosen content without having to cycle through all the tabs in the tablist each time. I have a demo of this here: http://heydonworks.com/practical_aria_examples/#tab-interface. (This doesn’t so far implement your other suggestions RE hashchange etc :-( ). There’s a note on widget keyboard interaction here: http://www.w3.org/WAI/PF/aria-practices/#kbd_general_within.
Heydon
Hi, Remy.
Cheers for the detailed post.
Just wanted to add that truly conventional, accessible tab interfaces have a specific way of handling keyboard operation: Only the left and right arrow keys should switch tabs and – simultaneously – reveal the associated panel. The TAB key is preserved for moving between the active TAB and the open panel. This means inactive tabs should have tabindex=”-1” and be focused/activated only programmatically (via the aforementioned arrow keys).
The reason for this is that keyboard and AT users should be afforded a direct route to the chosen content without having to cycle through all the tabs in the tablist each time. I have a demo of this here: http://heydonworks.com/practical_aria_examples/#tab-interface. (This doesn’t so far implement your other suggestions RE hashchange etc :-( ). There’s a note on widget keyboard interaction here: http://www.w3.org/WAI/PF/aria-practices/#kbd_general_within.