WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Navigating from tab to tab panel

for

From: Sailesh Panchang
Date: Sep 27, 2017 8:41AM

Birkir,
I think the definitions are quite clear:
Tablist: A list of tab elements, which are references to tabpanel elements.

Tabpanel: A container for the resources associated with a tab, where
each tab is contained in a tablist.

tablist elements are typically placed near, usually preceding, a
series of tabpanel elements.
(From the ARIA 1.1 Oct 2016 candidate rec.)
Sorry I do not see the vagueness you attributed to the descriptions
of the roles. Please can you point me to that content?
Thanks and Best regards,


On 9/27/17, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> There are two problems with nesting tabs and tabpanels in a tablist:
>
> 1. The screen reader announcement of the number of tabs in the tablist
> is inaccurate (because both the tabs and the tabpanels are in the
> tablist).
> 2. If the active tabpanel is displayed before tabs ths uer may find it
> difficult to locate/discover the other tabs (think of a situation
> where tabpenel 1 is displayed after tab 1 but before tabs 2 and 3).
> ON desktop this is ok, provided that the arrow key navigation was
> implemented, but on responsive devices without a keyboard, the user
> may have a very hard time finding the tabs after that tabpanel.
> 3. The ARIA spec is too vague, I am not sure if an element with
> role="tablist' is allowed to have children whose role is not tab. The
> spec says the tablist role must have at least one child with
> role="tab" but the required wned elements section does not say whether
> it is allowed to have descendant elements with other roles.
> The spec should make this clear.
>
>
>
> On 9/27/17, Mohith BP < <EMAIL REMOVED> > wrote:
>> Hi Mark,
>>
>> I agree with you regarding the unnecessary navigation.
>> The suggestion you proposed works good provided:
>> 1. Initially none of the tabs are expanded so that the user can
>> navigate between the list of tabs in both brows and focus modes.
>> 2. Once one of the tab is activated, the user should be able to
>> navigate between the list of tabs without encountering the expanded
>> tab panel. I think at least in focus mode this can be achieved.
>>
>> We have implemented the following:
>> 1. Tabs and tabpanel are arranged in the treditional order (as you
>> explained in first scenario).
>> 2. In the list of tabs when enter is pressed to activate the tab the
>> focus is automatically moved to the beginning of the tab panel with
>> JAVA script.
>> 3. Pressing shift + tab from the tab panel brings back the focus to
>> the active tab in the tablist.
>>
>> Note: This still has other issues such as if tab panel has any
>> actionable elements, focus cannot be brought back to the active tab as
>> logical tab focus need to be maintained.
>>
>> Proposal of providing a skip link at the end of the tabpanel back to
>> the tablist was mostly rejected by designers.
>>
>>
>> Thanks & Regards,
>> Mohith B. P.
>>
>> On 9/27/17, Mark Magennis < <EMAIL REMOVED> > wrote:
>>> 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
>>> >>> >>> >>> >>>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >


--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765