WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Navigating from tab to tab panel

for

From: Birkir R. Gunnarsson
Date: Sep 27, 2017 5:58AM

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.