.nav-tabs and .nav-pills ... should they always be role="tablist"?

[patrickhlauke]

This is in the context of https://github.com/patrickhlauke/bootstrap/commit/3425f961eed0f74695ca5f92f8e2bc1017febc4c#commitcomment-8379233 where I propose to drop the various role="tablist" from the "Navs" code as, in most cases, I'd argue those .nav-tabs and .nav-pills won't be used for actual tab panels, but to quickly style up a mini navigation (in which case role="tablist" would be wrong).

However, your tab.js is quoted as a counter-example

bootstrap-accessibility-plugin/src/js/tab.js

Line 8 in ecf7699

$tablist.attr('role', 'tablist')

... anything with .nav-tabs and .nav-pills automatically gets the role="tablist"

i do call out the fact that if it is in fact used for a tablist, it should have the additional roles in line 24 https://github.com/patrickhlauke/bootstrap/commit/3425f961eed0f74695ca5f92f8e2bc1017febc4c#diff-4807a8cd0881fb6cce944561f89bce81L24

In short: any thoughts on this? If people do use the "Navs" for something other than real tab panels (which I would argue they would), should it still be given role="tablist" which seems incorrect?

[patrickhlauke]

further context: looking at the example http://getbootstrap.com/examples/justified-nav/ it seems to me that the generic "Navs" component can be used for non-tab-panel navigations. As such, it would be wrong to indiscriminately add role="tablist" to them?

[patrickhlauke]

it seems that the indicator for when it is or isn't an actual tablist should be whether or not there are is determined primarily by the presence of data-toggle=tab / data-toggle=pill (see "Markup" on http://getbootstrap.com/javascript/#tabs-usage). so I think the logic in the tabs.js should only apply role=tablist in cases where there are actual data-toggle=tab / data-toggle=pill. If there aren't any (i.e. if
$tabs = $tablist.find('[data-toggle="tab"], [data-toggle="pill"]') comes back empty), then none of the remaining code (e.g.
$tablist.attr('role', 'tablist') $lis.attr('role', 'presentation') $tabs.attr('role', 'tab')
should be applied.

[mpnkhan]

So justified-tab will not have any tab panel is it? In the example you posted (http://getbootstrap.com/examples/justified-nav/), I could see 2 classes :
"nav nav-justified", whereas the Plugin code looks for ".nav-tabs, .nav-pills ",
var $tablist = $('.nav-tabs, .nav-pills')
In case you remove those role, it would appear as Unordered list to a screen reader. Is there any alternative you are proposing?

[patrickhlauke]

I'm saying that Paypal code seems to assume that any time there's a .nav-tabs or .nav-pills, (and, by enference, any kind of "Nav") this will be a tabpanel. the justified nav example shows that the concept of "Nav" can be used separately from whether or not it's a tabpanel, and tabs.js should therefore not immediately assume that the presence of .nav-tabs or .nav-pills also means that we're in the presence of a tabpanel and add roles

[patrickhlauke]

For instance, a designer may choose to use the exact code from http://getbootstrap.com/examples/justified-nav/ but replace nav-justified with nav-pills, purely because they like the look of it. But that would then not turn it into a tab panel that requires role="tablist"

[patrickhlauke]

"In case you remove those role, it would appear as Unordered list to a screen reader. Is there any alternative you are proposing?" if a "Nav" is used purely for navigation, rather than as a tablist for a tabpanel, then it should get whatever role the plugin here gives to other site navigations, if any.

[karlgroves]

"tabs" != "navigation"

This is (and menu) a very common misunderstanding, but it is important to keep in mind that navigation is a very different thing within a tabpanel context vs. a document (or even application) context.

In the WAI-ARIA authoring practices document this is explained a bit
http://www.w3.org/TR/2010/WD-wai-aria-practices-20100916/

3.2.5. Managing the Perception of a Dual Focus

Often applications give the perception of having a dual focus. Two examples of this are multi-selection list boxes and selected tabs, within a tablist, when focus is in a tabpanel. ... In the case of a tabpanel the user selects a tab but then navigates to a focused item in the corresponding tabpanel the tab appears to also have focus. In reality, only one element may have focus in an application. In these scenarios authors should ensure keyboard focus is set on the current element that visibly receives keyboard user input while ensuring other "highlighted" elements have an aria-selected state of "true" until de-selected. When the de-selection occurs, such as when ... a user moves to a new tab and de-select the old tab, the author should ensure that the visible selection of the de-selected item is removed.

In other words, the use of tab-related roles is only relevant in the context of a tabpanel. Navigation has an entirely different context - the entire document. No matter whether something looks like tabs or not, if they do not behave as tabs and operate in the context of a tabpanel (or, accordion) interface then they must not be given tab-related roles.

[mpnkhan]

1. Hi @cvrebert , Is this correct? "A designer may replace nav-justified with nav-pills, purely because they like the look of it." .
   Is there a specific way to know if the className is tabPanel, instead of leaving it to user , who may mistake it?
2. For http://getbootstrap.com/examples/justified-nav/ example, instead of stripping of ARIA role and leaving it as unordered list, won't this navigation role (http://www.w3.org/TR/2011/CR-wai-aria-20110118/roles#navigation) fit?
   @vick08/ @weboverhauls
   Thoughts?

[patrickhlauke]

"For http://getbootstrap.com/examples/justified-nav/ example, instead of stripping of ARIA role and leaving it as unordered list, won't this navigation role (http://www.w3.org/TR/2011/CR-wai-aria-20110118/roles#navigation) fit?"

My main point isn't specifically about that example per se, but the wider issue of: in the documentation for "Navs" http://getbootstrap.com/components/#nav we can't make an assumption about how devs are using these Navs (as navigation, or as actual tablist), so the demo example code should really not have any specific role applied to it (but provide guidance as a callout that does say "but make sure to use the right role")

[karlgroves]

+1 on documenting (inc. reference) some guidance on which roles to use rather than assuming which the developers' specific needs require.

[patrickhlauke]

How's about the following https://github.com/patrickhlauke/bootstrap/commit/b9913cd3bd3c95ce68bbac8462bfdb42b7d729a6 ? I moved (and slightly altered) the advice about using tabs plugin and the appropriate roles to the overall "Navs" part (as the same advice would apply in case where a developer chose to use a .nav-pills nav for a tab panel) AND added a new callout about navs being used for actual navigation (advising that role="navigation" should be used on the parent element, not the <ul> itself)

[patrickhlauke]

Here's a perhaps better example http://getbootstrap.com/examples/jumbotron-narrow/ - note how the .nav-pills has been used to provide a generic navigation, not a tablist (though somebody over-eagerly added role="tablist" in the example code). This is clearly not a case of tablist...so the presence or not of .nav-pills (or even .nav-tabs for that matter) is not a sure-fire indication of the intent of the author to make a "real" tabbed inteface

[cvrebert]

Is this correct? "A designer may replace nav-justified with nav-pills, purely because they like the look of it." .

Yes, that's correct. Tabs and Pills can currently also be used as general navigation widgets, without any associated panel whose content changes based on selected tab/pill.

Is there a specific way to know if the className is tabPanel, instead of leaving it to user , who may mistake it?

Currently, not that I know of, short of something hacky like $($('.nav>li:first-child>a').attr('href')).is('.tab-pane')