E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 4 (In chronological order)

From: Moore,Michael (Accessibility) (HHSC)
Date: Tue, Apr 19 2016 2:15PM
Subject: Troubleshooting hint on tab-panel
No previous message | Next message →

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)

From: Bryan Garaventa
Date: Tue, Apr 19 2016 3:17PM
Subject: Re: Troubleshooting hint on tab-panel
← Previous message | Next message →

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 ADDRESS REMOVED =
415.624.2709 (o)
www.SSBBartGroup.com

From: Moore,Michael (Accessibility) (HHSC)
Date: Tue, Apr 19 2016 3:23PM
Subject: Re: Troubleshooting hint on tab-panel
← Previous message | Next message →

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)

From: Birkir R. Gunnarsson
Date: Tue, Apr 19 2016 3:35PM
Subject: Re: Troubleshooting hint on tab-panel
← Previous message | No next message

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 ADDRESS 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)
>
>