Where to place the aria-controls attribute in my tabs markup

Question

I'm setting up a tabbed content section in my page using a script that follows the following syntax:

<!-- Clickable tab links -->
<ul class="js-tablist">
    <li id="tab1" class="js-tab active"><a href="#tabpanel1">Tab 1</a></li>
    <li id="tab2" class="js-tab"><a href="#tabpanel2">Tab 2</a></li>
    <li id="tab3" class="js-tab"><a href="#tabpanel3">Tab 3</a></li>
</ul>

<!-- Tab panels -->
<div id="tab-set" class="js-tabpanel-group">
    <section id="tabpanel1" class="js-tabpanel">__CONTENT__</section>
    <section id="tabpanel2" class="js-tabpanel">__CONTENT__</section>
    <section id="tabpanel3" class="js-tabpanel">__CONTENT__</section>
</div>

I will be setting various ARIA roles (role="tablist", role="tab", role="tabpanel", etc) on this structural markup via javascript (since if there's no scripting then there are no tabs) but I'm unsure quite where to place my ‘aria-controls’ attributes. Should they go on the <li> element or on its <a> child element? Or does it not matter? Indeed, the same question could be asked about role="tab" and tabindex="0" -- should these things go on the list item or the anchor?

Solution 1

Put aria-controls on the item that gets role="tab".

aria-controls is what creates the relationship between a tab and its panel. See the third bullet in the description for aria-controls from the spec: https://www.w3.org/TR/wai-aria-1.1/#aria-controls

To answer your follow-on question, put the role="tab" on the <a href> since that is already primed to receive keyboard focus and be actionable by the browser. That also means you won't need to use tabindex at all.

Consider also throwing a role="presentation" on the <li> elements and role="tablist" on the <ul> (especially since you rendering the <li> inert with role="presentation").

Be prepared to also manage arrow key navigation, as by using the tab roles you are essentially telling an expert user that these tabs will behave like tabs in the OS, which honor arrow keys to switch between tabs.

Additional resources worth checking out:

• https://www.marcozehe.de/2013/02/02/advanced-aria-tip-1-tabs-in-web-apps/ (from the guy who works on accessibility at Mozilla and is a screen reader user)
• http://heydonworks.com/practical_aria_examples/#tab-interface (from a guy who does accessibility consulting and remediation)

After all this, please test it in screen readers to make sure it behaves as you expect.

Solution 2

This demo shows a screen reader using tabpanels with ARIA. The Jaws screen reader provides a shortcut for moving from the tab to the corresponding tabpanel based on the relationship created by the aria-controls attribute.

If you're curious, this demo shows a screen reader using tabpanels without ARIA.

When you create a set of tabpanels you want the widget to represent a single tab stop in the keyboard order. When someone uses the tab key to move onto the set of tabs, focus should go to the currently selected tab, and the next press of the tab key should take focus back into the content again.

You can use a roving tabindex to do this. Only the currently selected tab should be focusable. All other tabs (specifically the <a> elements that represent them) should have tabindex="-1" set. This prevents them from being included in the keyboard tab sequence.

The scripting that enables someone to cycle through the tabs useing the left/right arrow keys should also update the values of the tabindex attribute on each tab, so that all but the currently selected tab have tabindex set to -1. There is a working tabpanels demo here.

Comments

[RickL]

Thanks for those demoes Léonie. The use of tabindex in an accessibility context has always been a bit of a mystery for me; first using tabindex was recommended, then it was not recommended (to avoid conflicting with pre-existing keyboard shortcuts), and now it's recommended but with a fairly arcane set of rules. Definitely something I need to look into more. Cheers.

[Léonie Watson]

The tabindex attribute was updated in HTML5. It's still possible to use it to make things horrible, but it's also ok. This article on <a href="paciellogroup.com/blog/2014/08/using-the-tabindex-attr‌​ibute/… the tabindex attribute</a> might be helpful.

[RickL]

Smashing, thanks Léonie. I already have a bunch of bookmarks for pages at paciellogroup.com and I'll add that one to the collection. FWIW, your link seems to have become garbled; the correct URL is paciellogroup.com/blog/2014/08/using-the-tabindex-attribute (although if the garbling occurred as part of Stack Overflow's commenting system then of course mine might get similarly mangled).

[Phil Gyford]

The w3.org link 404s. This might be a suitable substitute: w3.org/TR/wai-aria-1.1/#aria-controls