WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Navigating from tab to tab panel

for

From: mhysnm1964@gmail.com
Date: Sep 27, 2017 5:56AM

Extracted this from the ARIA best practise 1.1 guide which is what you are saying:

Permalink for 2.23 Tabs

Tabs are a set of layered sections of content, known as tab panels, that display one panel of content at a time. Each tab panel has an associated tab element,
that when activated, displays the panel. The list of tab elements is arranged along one edge of the currently displayed panel, most commonly the top edge.


Terms used to describe this design pattern include:

definition list of 4 items
Tabs or Tabbed Interface

A set of tab elements and their associated tab panels.

Tab List

A set of tab elements contained in a
tablist
element.

tab

An element in the tab list that serves as a label for one of the tab panels and can be activated to display that panel.

tabpanel

The element that contains the content associated with a tab.
list end

When a tabbed interface is initialized, one tab panel is displayed and its associated tab is styled to indicate that it is active. When the user activates
one of the other tab elements, the previously displayed tab panel is hidden, the tab panel associated with the activated tab becomes visible, and the tab
is considered "active".

Examples
list of 2 items
- Tabs With Automatic Activation:
A tabs widget where tabs are automatically activated and their panel is displayed when they receive focus.
- Tabs With Manual Activation:
A tabs widget where users activate a tab and display its panel by pressing Space or Enter.
list end

Keyboard Interaction

For the tab list:

list of 3 items
- Tab: When focus moves into the tab list, places focus on the active tab element . When the tab list contains the focus, moves focus to the next element
in the page tab sequence outside the tablist, which is typically either the first focusable element inside the tab panel or the tab panel itself.
- When focus is on a tab element in a horizontal tab list:
list of 2 items nesting level 1
◦ Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See
note below).
◦ Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused
tab (See note below).
list end nesting level 1
- When focus is on a tab in a tablist with either horizontal or vertical orientation:
list of 5 items nesting level 1
◦ Space or Enter: Activates the tab if it was not activated automatically on focus.
◦ Home (Optional): Moves focus to the first tab
◦ End (Optional): Moves focus to the last tab.
◦ Shift + F10: If the tab has an associated pop-up menu, opens the menu.
◦ Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel. If any tabs remain, sets focus to the
tab following the tab that was closed and activates the newly focused tab. Alternatively, or in addition, the delete function is available in a context
menu.
list end nesting level 1
list end

NOTE
list of 3 items
1. It is recommended that tabs activate automatically when they receive focus as long as their associated tab panels are displayed without noticeable latency.
This typically requires tab panel content to be preloaded. Otherwise, automatic activation slows focus movement, which significantly hampers users' ability
to navigate efficiently across the tab list. For additional guidance, see
4.4 Deciding When to Make Selection Automatically Follow Focus.
2. If the tabs in a tab list are arranged vertically:
list of 2 items nesting level 1
A. Down Arrow performs as Right Arrow is described above.
B. Up Arrow performs as Left Arrow is described above.
list end nesting level 1
3. If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even
when focus is inside the tab list.
list end

WAI-ARIA Roles, States, and Properties
list of 8 items
- The element that serves as the container for the set of tabs has role
tablist.
- Each element that serves as a tab has role
tab
and is contained within the element with role tablist.
- Each element that contains the content panel for a tab has role
tabpanel.
- Each element with role tab has the property
aria-controls
referring to its associated tabpanel element.
- The active tab element has the state
aria-selected
set to true and all other tab elements have it set to false.
- Each element with role tabpanel has the property
aria-labelledby
referring to its associated tab element.
- If a tab element has a pop-up menu, it has the property
aria-haspopup
set to true.
- If the tablist element is vertically oriented, it has the property
aria-orientation
set to vertical. The default value of aria-orientation for a tablist element is horizontal.
list end

Sorry if the links did not come through correctly for the examples.

Sean
-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Mark Magennis
Sent: Wednesday, 27 September 2017 8:16 PM
To: Webaim Forum < <EMAIL REMOVED> >
Subject: [WebAIM] Navigating from tab to tab panel

Hi everyone.

I've a question about how tabbed interfaces work with a screen reader. Usually, it seems, the tabs are in a list which is followed by a bunch of divs, each containing a tab panel. If so, when the user activates a tab and its panel opens, in order to get to the content (leaving aside the JAWS Ins+Alt+M shortcut as it's only JAWS), they have to arrow down through the remaining tabs first.

This seems unintuitive. It would seem more natural that when you open a tab, it's contents appear immediately after it, not with all the other tabs in between. So instead of this ordering:

Tab 1
Tab 2
Tab 3
Tab 1 panel
Tab 2 panel
Tab 3 panel

you would have this:

Tab 1
Tab 1 panel
Tab 2
Tab 2 panel
Tab 3
Tab 2 panel

In both cases, of course, only the open panel would be exposed.

I'm wondering has anyone tried to do it this way? Does anything think it's worth doing it this way, or is it likely to cause other usability problems? Should it just be accepted that the panels normally come after the whole tab list?

If anyone has done it this other way, then I'd be interested in seeing how. It seems it would involve placing the panel directly after the tab in the DOM, but because the tab is a list item, this would make the panel its child would it? Which sounds strange.

Thanks,
Mark

Mark Magennis | Accessibility Support Manager InterAccess.ie <http://interaccess.ie/>; - Accessible UX