WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Any ARIA conforming tab panels out there in the wild?

for

From: Birkir R. Gunnarsson
Date: May 18, 2018 1:19PM

The priary problem for screen reader users is the arrow key behavior
of tabs that requires atomatically switching to
application/forms/interactive modes.

To do this Jaws maps tabs to a combobox widget (you can navigate to
tabs with the c shortcut key), Voiceover maps it to radiobuttons (at
least last time I tested).
Sure users can use arrow keys to navigate between tabs, but once they
select a tab they're stuck in the wrong mode for exploration and have
to get out of it manually (pressing the escape ke twice or
NVDAKey-spacebar or Jawskey-;).
In a recent tab implementation we made the tabpanel element ocusable
to enable users to tab out of the tabs and force the mode switching,
but it adds an additional tab stop with no function which people could
find equally confusing.
I'll post a URL of a page where we use this on Monday. I am on
vacation for a few days and trying to take it seriously. The arrow key
behavior causes extra JavaScript coding for developers and confusion
for screen reader users. I quite frankly don't think it's very
effective.

I think a more effective tab recommendation would be to keep al tabs
focusable and require implementing a keyboard shortcut (like page
down) o get from the selected tab to the associated tab panel.
I am not going to recommend dropping the tab implementation altogether
and fake it with links, there is important info in knowing that a set
of elements controls display of dynamic content on the page, but I
think the implementation could be simplified.
All that being said the aria-controls attribute is only supported in
Jaws and requires the complex keyboard shortcut JawsKey-alt-m. There
is an article out there explaining how aria-controls is useless. I
wouldn't quite go that far but I agree with the premise of the
article, aria-oontrol is badly supported and often has little
practical value.
It primarily has value when an element controls content that Is not
inline (next to it in the kcontent order), when updating quantity or
price of an item in a shopping cart updates the total amount.




On 5/18/18, glen walker < <EMAIL REMOVED> > wrote:
> How JAWS decided to implement aria-controls is somewhat tangential. It
> certainly helps being a piano player to hit JAWS+alt+m to get to the
> controlled element, but if JAWS had chosen an easier combination, the
> navigation would be much better. But that doesn't really affect how this
> example implemented the authoring practice recommendation for tabs, which
> is what was asked for.
>
> Other examples can be seen on
> https://www.sas.com/en_us/software/visual-analytics/demo.html
>
> All the examples seem to have a focusable element in the tab panel so that
> after selecting a tab, instead of using JAWS+alt+m, you can just tab once
> and you're in the tab panel.
>
>
> On Fri, May 18, 2018 at 10:13 AM, Steve Green <
> <EMAIL REMOVED> > wrote:
>
>> That example works ok with keyboard navigation but it's not a great user
>> experience with JAWS. In common with most, but not all, examples of tabbed
>> interfaces it's necessary to use the hideous Alt+Insert+M shortcut to get
>> to the tabpanel.
>>
>> I find this to be the most difficult of all the JAWS shortcuts and I would
>> be interested to know what JAWS users think of it. In fact, I wonder how
>> many JAWS users ever use it, other than professionals like the people on
>> this forum. Has anyone done any user testing with tabbed interfaces? I am
>> tempted to include this example in the next project we do even though it's
>> unrelated to anything we will be working on.
>>
>> Regards,
>> Steve Green
>> Managing Director
>> Test Partners Ltd
>>
>>
> > > > >


--
Work hard. Have fun. Make history.