E-mail List Archives
Thread: tabbed interfaces - tricky question
Number of posts in this thread: 7 (In chronological order)
From: Detlev Fischer
Date: Tue, Oct 30 2018 8:59AM
Subject: tabbed interfaces - tricky question
No previous message | Next message →
I have a tricky question for tabbed interfaces / tab panel aficionados.
We know there are two different beasts, 1 and 2:
1. tabbed navigation - looks like tabs but is a menu going to other
section pages
Here, consensus is that tabbed interfaces with ARIA should not be used,
this is just a list of links in a nav
2. True tab panels / tabbed navigation (on one and the same page)
Here, people can opt for the implementation according to ARIA best
practices (tablist is one tab stop, then use arrow keys to navigate
between tabs, possibly make panel the next tab stop, or implement down
arrow for focusing panel); or have a mixed implementation where tabs can
be focused with both arrow keys AND the tab key (because this is what
many users expect)
Now there are implementations where you have something that *looks* like
a tab panel on one and the same page (i.e., *only* the content in the
panel and state of the tab list change, the rest of the page -- title,
other content -- stays exactly the same) BUT in fact activating tabs
loads up different pages that differ only in terms of the panel content.
What would be your recommendations for implementing such a panel? Should
it appear and behave like an ARIA panel even if it loads different pages
(possibly using the focus() method to set focus to the activated tab
after page load?) Unfortunately I cannot show the example that brought
up this queston since it is in a password-protected area of a customer's
site.
Detlev
--
---------------------------------------------------------------
Detlev Fischer PhD
DIAS GmbH - Daten, Informationssysteme und Analysen im Sozialen
Geschäftsführung: Thomas Lilienthal, Michael Zapp
Telefon: +49-40-43 18 75-25
Mobile: +49-157 57 57 57 45
Fax: +49-40-43 18 75-19
E-Mail: = EMAIL ADDRESS REMOVED =
Anschrift: Haubachstr. 72, D-22765 Hamburg
Amtsgericht Hamburg HRB 58 167
Geschäftsführer: Thomas Lilienthal, Michael Zapp
---------------------------------------------------------------
--
Detlev Fischer
Testkreis
Werderstr. 34, 20144 Hamburg
Mobil +49 (0)157 57 57 57 45
http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites
---
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus
From: Patrick H. Lauke
Date: Tue, Oct 30 2018 9:01AM
Subject: Re: tabbed interfaces - tricky question
← Previous message | Next message →
On 30/10/2018 14:59, Detlev Fischer wrote:
> I have a tricky question for tabbed interfaces / tab panel aficionados.
>
> We know there are two different beasts, 1 and 2:
>
> 1. tabbed navigation - looks like tabs but is a menu going to other
> section pages
> Here, consensus is that tabbed interfaces with ARIA should not be used,
> this is just a list of links in a nav
>
> 2. True tab panels / tabbed navigation (on one and the same page)
> Here, people can opt for the implementation according to ARIA best
> practices (tablist is one tab stop, then use arrow keys to navigate
> between tabs, possibly make panel the next tab stop, or implement down
> arrow for focusing panel); or have a mixed implementation where tabs can
> be focused with both arrow keys AND the tab key (because this is what
> many users expect)
>
> Now there are implementations where you have something that *looks* like
> a tab panel on one and the same page (i.e., *only* the content in the
> panel and state of the tab list change, the rest of the page -- title,
> other content -- stays exactly the same) BUT in fact activating tabs
> loads up different pages that differ only in terms of the panel content.
> What would be your recommendations for implementing such a panel? Should
> it appear and behave like an ARIA panel even if it loads different pages
> (possibly using the focus() method to set focus to the activated tab
> after page load?) Unfortunately I cannot show the example that brought
> up this queston since it is in a password-protected area of a customer's
> site.
Treat it still like a navigation (1. in the above example), as i'd
suspect the whole roundtrip of loading a new page, setting focus, etc
will be slower than the expected immediacy of a true tab panel - and
users may also be confused by the fact it does a page load (e.g. if
their AT announces that a load happened)
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Isabel Holdsworth
Date: Tue, Oct 30 2018 9:47AM
Subject: Re: tabbed interfaces - tricky question
← Previous message | Next message →
A developer asked me the same question this morning, and we came to
the same conclusion.
I'd find it very confusing, as a screenreader user, if I pressed an
arrow key to view a different tab panel and the focus was changed.
Even if it was put back to the tab that initiated the change, JAWS
would come out of, and possibly back into, forms or application mode,
which would be confusing and frustrating.
On 30/10/2018, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 30/10/2018 14:59, Detlev Fischer wrote:
>> I have a tricky question for tabbed interfaces / tab panel aficionados.
>>
>> We know there are two different beasts, 1 and 2:
>>
>> 1. tabbed navigation - looks like tabs but is a menu going to other
>> section pages
>> Here, consensus is that tabbed interfaces with ARIA should not be used,
>> this is just a list of links in a nav
>>
>> 2. True tab panels / tabbed navigation (on one and the same page)
>> Here, people can opt for the implementation according to ARIA best
>> practices (tablist is one tab stop, then use arrow keys to navigate
>> between tabs, possibly make panel the next tab stop, or implement down
>> arrow for focusing panel); or have a mixed implementation where tabs can
>> be focused with both arrow keys AND the tab key (because this is what
>> many users expect)
>>
>> Now there are implementations where you have something that *looks* like
>> a tab panel on one and the same page (i.e., *only* the content in the
>> panel and state of the tab list change, the rest of the page -- title,
>> other content -- stays exactly the same) BUT in fact activating tabs
>> loads up different pages that differ only in terms of the panel content.
>> What would be your recommendations for implementing such a panel? Should
>> it appear and behave like an ARIA panel even if it loads different pages
>> (possibly using the focus() method to set focus to the activated tab
>> after page load?) Unfortunately I cannot show the example that brought
>> up this queston since it is in a password-protected area of a customer's
>> site.
>
> Treat it still like a navigation (1. in the above example), as i'd
> suspect the whole roundtrip of loading a new page, setting focus, etc
> will be slower than the expected immediacy of a true tab panel - and
> users may also be confused by the fact it does a page load (e.g. if
> their AT announces that a load happened)
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >
From: glen walker
Date: Tue, Oct 30 2018 9:57AM
Subject: Re: tabbed interfaces - tricky question
← Previous message | Next message →
Just to add to the consensus that Patrick and Isabel have already posted, I
don't think there are two types of tab panels. The first one you described
(and the third one you described, which is the basis of your question) is
just a navigation menu (but not a "menu" in the true sense of the word like
an application menu and role="menu" - that's a whole nother discussion).
If the nav menu is visually styled to look like tabs, that's ok. When you
select an item, if a new page loads but looks exactly like the previous
page but with new contents in the "tab" area, that's ok too. It's still
just a basic link to a new page and should be implemented as a basic link
navigation. No tab roles should be used.
From: Mohith BP
Date: Wed, Oct 31 2018 4:10AM
Subject: Re: tabbed interfaces - tricky question
← Previous message | Next message →
"the rest of the page -- title, other content -- stays exactly the
same) BUT in fact activating tabs loads up different pages
that differ only in terms of the panel content."
The rest of the page especially title remains same and you are telling
it is a page refresh affecting only the panel content.
1. If this panel content you are mentioning is the main content then
the title of the page need to match to the content displayed.
2. If this tab panel content is just a small portion of the page then
I don't see how this can be a page refresh.
3. As already mentioned by others 1 and 3 scenarios need not be ARIA
tab specifications.
Thanks & Regards,
Mohith B. P.
On 10/30/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> Just to add to the consensus that Patrick and Isabel have already posted, I
> don't think there are two types of tab panels. The first one you described
> (and the third one you described, which is the basis of your question) is
> just a navigation menu (but not a "menu" in the true sense of the word like
> an application menu and role="menu" - that's a whole nother discussion).
> If the nav menu is visually styled to look like tabs, that's ok. When you
> select an item, if a new page loads but looks exactly like the previous
> page but with new contents in the "tab" area, that's ok too. It's still
> just a basic link to a new page and should be implemented as a basic link
> navigation. No tab roles should be used.
> > > > >
From: Mallory
Date: Wed, Oct 31 2018 9:12AM
Subject: Re: tabbed interfaces - tricky question
← Previous message | Next message →
One thing I want to say,
quote: "If the nav menu is visually styled to look like tabs, that's ok."
Sighted keyboarders can never tell one from the other. Not only is there no universal design difference between navving and panelling tabs, but Material Design has made it worse by teaching designers that the page links style are called "tabs" (that's the component name) and with single-page apps it gets blurry between a panel content changed and a View changed (devs don't always remember to change the <title> text and focus can end up... anywhere).
I've started thinking I'll toss a coin every time I see something that vaguely looks tabby to see how I should try to navigate it first. The uncertainty is unsettling, takes me out of my mindset for the task I was trying to do, and I have to re-learn whatever is the "right" way on every new website. Unlike an SR user I don't get the benefit of being told about any aria roles or anything (although I've seen so many "tab panels" with all the right aria markup but none of the correct JS that that may not be so helpful anyway).
I wish browsers offered something to tell me wft the thing is (visibly) so I can just use it without playing a game first. But so anyway, ideally a single website does not switch between the behaviours, and if it must, style them radically differently please.
cheers,
_mallory
On Wed, Oct 31, 2018, at 11:10 AM, Mohith BP wrote:
> "the rest of the page -- title, other content -- stays exactly the
> same) BUT in fact activating tabs loads up different pages
> that differ only in terms of the panel content."
>
> The rest of the page especially title remains same and you are telling
> it is a page refresh affecting only the panel content.
> 1. If this panel content you are mentioning is the main content then
> the title of the page need to match to the content displayed.
> 2. If this tab panel content is just a small portion of the page then
> I don't see how this can be a page refresh.
> 3. As already mentioned by others 1 and 3 scenarios need not be ARIA
> tab specifications.
>
>
> Thanks & Regards,
> Mohith B. P.
>
>
>
>
> On 10/30/18, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> > Just to add to the consensus that Patrick and Isabel have already posted, I
> > don't think there are two types of tab panels. The first one you described
> > (and the third one you described, which is the basis of your question) is
> > just a navigation menu (but not a "menu" in the true sense of the word like
> > an application menu and role="menu" - that's a whole nother discussion).
> > If the nav menu is visually styled to look like tabs, that's ok. When you
> > select an item, if a new page loads but looks exactly like the previous
> > page but with new contents in the "tab" area, that's ok too. It's still
> > just a basic link to a new page and should be implemented as a basic link
> > navigation. No tab roles should be used.
> > > > > > > > > >
> > > >
From: glen walker
Date: Wed, Oct 31 2018 12:42PM
Subject: Re: tabbed interfaces - tricky question
← Previous message | No next message
Yes, Mallory, I agree that the visual cues for sighted users is a bit
blurred, and I have the same problem you do. My default action is to tab
through the interface and if that doesn't work (because the tab key went to
the first tab-looking thing but the second tab key jumped to the next
focusable element after the tab list), then I tab back and use the arrow
keys. It's not ideal, and is a minor annoyance, but I can still get my
work done.
As a related aside, see the previous discussion
<https://webaim.org/discussion/mail_thread?thread=8966> earlier this month
regarding whether screen reader users use the tab key to navigate.