WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: tabpanel mark-up, possible effect of role=presentation

for

From: Birkir R. Gunnarsson
Date: Aug 6, 2015 7:33AM

Hi

This sounds like the site is using some Javascript that does things it
should do.
The tab mak-up should be
<code>
<ul role="tablist">
<li role="presentation" aria-controls="tabp1" id="tab1"><a href="#"
role="tab" aria-selected="true">Tab 1</a></li>
<li role="presentation"><a href="#" tabindex="-1" role="tab"
aria-controls="tabp2">Tab 2</a></li>
....
</ul>
...
<div role="tabpanel" aria-labelldby="tab1" id="tab1" tabindex="-1">
..
</div>
</cide>

You use role tablist on the list containing the tabs.
YOu use role presentation on the li elements to enable screen readers
to calculate the number of tabs .. because the tabs should be direct
children of tablist (if you skip those the screen readers will read "1
of 1" for each tab, which is not the end of the world).
Only the active tab should be in taborder (hence abindex="-1" on other tabs).
You need JavaScript to implement the arrow key navigation.
When user navigates to a tab with the arrow key, the aria-selected
attribute should be moved and tabpanel content should become visible.
But focus should not be ripped away from the user and forced into the
content. The user might just be exploring what tabs are available,
that would be a WCAG 3.2.2 violation.
There are some example tab implementations with live example as well
as downloadable code on http://dequeuniversity.com (under "examples
and resources").
I am partially responsible for some of them, particularly the
responsive tabs to accordion example (tabs don't work well on phones
so we decided to think responsively .. just like we drink
responsibly).
Also check out the tabpanel example in the WAI-ARIA Authoring Best Practices.

And, remember, ARIA only tells screen reader what something is, it
does not make it act differently. All that is for the developers to
do.
If I say
<span role="link">Google</span>
it does not make the span focusable or take user to Google when user
clicks on it.
If you set a tabindex="0" on the span and associate JavaScript that
detected click events and took the user to Google, then you actually
have a link.
Now you are just lying to the (screen reader) user that your span is a link.
He will her the word "link" announced when he navigates with his arrow
keys in screenreader virtual buffer, but he cannot put focus on it or
activate it or anything.

Cheers
-B


On 8/6/15, Detlev Fischer < <EMAIL REMOVED> > wrote:
> Hi,
>
> I have a question for screen reader users. Curently I am testing a site that
> uses what appears to be a properly marked-up tabpanel: two tabs with role
> tab, content in two divs with role tabpanel. The tabs are technically skip
> links to the associated tabpanel divs. These two tab links sit inside li
> elements with role=presentation. The site also use aria-selected on the tabs
> and aria-hidden=true and display=none on the hidden tabpanel.
>
> Now my question: when navigating with arrow keys in NVDA and JAWS (Firefox),
> both screen readers do not read the tabs - they skip straight to the
> tabpanel content below. I fist though this might be due to role=presentatino
> on the li elements, but this role should not apply to the a elements inside
> the li elements, if I correctly understand the ARIA semantics.
>
> Tabbing through content will focus and rtead the tabs, but fail to read the
> tabpanel content when arrowing doen after activation (just a visible scroll
> effect).
> Could well be that I am not using the screen readers correctly. Or is this
> due to known screen reader bugs?
> Unfortunately I cannot point you to the site (behind a login).
>
> Any ideas?
>
> --
> Detlev Fischer
> testkreis c/o feld.wald.wiese
> Thedestr. 2, 22767 Hamburg
>
> Mobil +49 (0)1577 170 73 84
> Tel +49 (0)40 439 10 68-3
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
> > > > >


--
Work hard. Have fun. Make history.