WCAG has a great design pattern for implementing Tabs with Tabpanels here
It uses a "roving tab index", and keyboard arrow keys to cycle between tabs. This works great, but I recently received a request to make a tab/tabpanel widget that only shows one tab at a time, and has "previous" and "next" arrow buttons to cycle through the tabs.
Visually, the arrow buttons are on either side of the active tab. But in terms of tab-order, the WCAG design pattern specifically states that the tabpanel associated with the active tab should follow it in tab order.
Would it violate any accessibility rules to add these new arrow nav buttons to the widget, as long as I assure that their tab order is before or after the tabs/tabpanels? I figure the keyboard functionality could remain as it currently is (using arrow keys to cycle between tabs)
I'm a blind screen reader user. I would maintain left/right arrow keys to navigate through the tabs as usual, and don't make your arrow buttons focusable at all.
My reasoning behind this is the following:
IF you take a multiline text area for example, the down arrow always goes to the next line, regardless of whether the cursor is currently at the bottom of the screen. We don't have anything special to do, and especially we don't have to manually press the down arrow button of the scroll bar. The cursor goes to the next line, and the text content is automatically scrolled one line down if needed.
The same things happen for a tab control if there are too many tabs to fit on a single line. In that case, in popular GUI desktop libraries, you can choose to show scroll arrow buttons, or make the tabs spand multiple lines. It never change the way to navigate: left and right arrow keys always go to the next or previous tab, regardless of what has to happen visually.
As a bonus, usually, when you click on a scrollbar button, the focus doesn't go to the button; it immediately goes back to the real content, i.e. the text in the text area, or the currently active tab for a tab control. This is one or more confirmation that scroll buttons shouldn't enter in tab order.
As another bonus, given that you are implementing scroll buttons on your own, you should also react to mouse wheel.