WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Navigating from tab to tab panel

for

From: Birkir R. Gunnarsson
Date: Sep 28, 2017 9:47AM

Mark

The screen reader user would only have to move past a couple of tab
controls to get to the tabpanel (anywhere from 0 to maybe 5 or 6, at
least I have not seen more tabs in a tabbed interface). By correctly
using aria-controls you are also offering screen readers the ability
to take users straight to the tabpanel (sadly only Jaws implements
functionality for this attribute, but we can file issues to get more
vendors to take advantage). If you make the tabpanel focusable the
user can also get directly to it fro mthe tab by pressing the tab key
(assuming the tabpanel is located next to the tabs in the page csource
code order).

Contrast this with putting the the user having to navigate through all
the contents of a tabpanel to get to the remaining tabs (e.g. if tab 1
is activated, the order is tab1, tabpanel1, tab 2, tab 3). A tabpanel
can contain a lot of data with headings and links and stuff, and there
is no easy way for the user to jump directly past it to tabs 2 and 3.

It is certainly hard to implement the perfect interface for all users,
but I think between these two approaches keeping the tabs together is
the better approach (plus it is semantically correct while the other
is not per the ARIA standard).



On 9/28/17, Mark Magennis < <EMAIL REMOVED> > wrote:
> The language does make this confusing and I think you misunderstood me
> Sailesh. In the non-working solution I mentioned, it is the tab buttons that
> are temporarily hidden, not the tab panels. As you say, the closed tab
> panels are always hidden. I say "temporarily" because that seems to be the
> intent, except the developers seem to have forgotten to unhide them. The
> idea behind this approach is that when the screen reader user opens a tab
> panel by activating its tab button, it appears as if the tab panel comes
> immediately after its tab button. No need to go through the other buttons to
> get there. I think this is a good idea, but it involves unhiding the hidden
> tab buttons after the user has moved. Now that I think about this even more
> though, I guess its possible that a user may decide to open a different
> panel before moving (say they realise they accidentally clicked the wrong
> tab button, or they just change their mind). Having to move away and back
> again in order to make the other tab buttons spring back into life would be
> strange to say the least and it would be obvious that there is some kind of
> voodoo going on, which is always a bit disconcerting I think.
>
> Anyways, thanks guys for the suggestions.
>
> Mark
>
> Mark Magennis | Accessibility Support Manager
> InterAccess.ie <http://interaccess.ie/>; - Accessible UX
>
>> On 27 Sep 2017, at 17:42, Sailesh Panchang < <EMAIL REMOVED>
>> <mailto: <EMAIL REMOVED> >> wrote:
>>
>> Mark,
>> The tab panels all (except the active tab) have to be hidden ie. not
>> rendered for all users so display: none should be toggled. No use for
>> aria-hidden IMO.
> > > > >


--
Work hard. Have fun. Make history.