WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Troubleshooting hint on tab-panel

for

From: Birkir R. Gunnarsson
Date: Apr 19, 2016 3:35PM

Bryan is probably right.
I have often seen developer put role="tab" on what should be the
tabpanel content.
It makes a bit of sense, especaily if you want to make accessible tabs
but don't spend enough time reading the manual (it is a little tricky
the first time).
The 3 steps of accessible tab ARIA roles and attributes:
1. All the tabs need to be contained in an element with role="tablist"
(that way screen readers can announce the number of tabs).
2. The element that is activated to show different content
* has role of tab
* has an aria-controls attribute pointing to the ID of the tabpanel.
* has aria-selected="true" if it is active.
3. The container that is displayed or hidden when a tab is activated
* has a role of tabpanel (not tab)
* has aria-labelledby pointing back to the id of the tab that controls it.

The rest is keyboard accessibility, CSS and focus management.



On 4/19/16, Moore,Michael (Accessibility) (HHSC)
< <EMAIL REMOVED> > wrote:
> Thanks Bryan,
>
> I will do that. I am away from the test environment today but it sounds like
> that is correct. I think that the developers may have put the tab role on
> the area that should have the tabpanel role. I will look for that first.
>
> You may have saved me a few hours of digging...
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
> (512) 438-3431 (Office)
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Bryan Garaventa
> Sent: Tuesday, April 19, 2016 4:18 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Troubleshooting hint on tab-panel
>
> It sounds like you are including the additional active elements inside of
> the container that includes role="tab", which would not be valid. It's
> difficult to diagnose this sight unseen though.
>
> If you run Visual ARIA on it
> http://whatsock.com/training/matrices/visual-aria.htm
>
> Then attempt to tab around and interact with the tab elements using the
> keyboard, do you see any errors in red?
>
>
>
> Bryan Garaventa
> Accessibility Fellow
> SSB BART Group, Inc.
> <EMAIL REMOVED>
> 415.624.2709 (o)
> www.SSBBartGroup.com
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf
> Of Moore,Michael (Accessibility) (HHSC)
> Sent: Tuesday, April 19, 2016 1:15 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: [WebAIM] Troubleshooting hint on tab-panel
>
> I am working with an internal development team that is implementing a form
> that uses tab-panels.
>
> The aria attributes that show and hide each tab appear to be working
> correctly.
>
> We do seem to have a couple of problems with some of the behavior in JAWS
> and NVDA in IE11 and in FireFox.
>
> The checkboxes, text fields, and radio buttons are implemented using
> appropriate html elements. However all of the <input type="text" ...> fields
> are reported as a "tab" instead of as a text field by the screen readers.
> The checkboxes, select elements, and radio buttons are reported correctly?
>
> Has anyone seen this before and what should I be looking for in the source
> code to help them resolve the issue.
>
> Sorry, I cannot provide access to the code at this time.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission Civil Rights Office
> (512) 438-3431 (Office)
>
> > > http://webaim.org/discussion/archives
> > > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.