WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Focus reset

for

From: Mark Magennis
Date: Apr 19, 2023 2:17AM

I think the reason most tab bar patterns allow only arrow key selection of tabs and not tabbing between tabs is that this follows a general pattern for UI widgets that you tab into and out of the widget and use arrow keys to navigate within it. This pattern is explained in the ARIA Authoring Practices document 'Developing a Keyboard Interface' (https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/) under 'Fundamental Keyboard Navigation Conventions'.

The benefit of this 'tab in, tab out' pattern for keyboard users is that if you don't want to interact with a widget you can get past it very quickly without having to tab through everything inside it. However, for most tab bars this doesn't really save you much effort because they generally contain only a few tabs. But for controls like a file hierarchy tree view or an interactive grid it can be essential.

Another thing about tab bars is that most often the tabs are scripted to activate automatically on focus. That is, when you go to a tab its tab panel appears without you having to activate it by pressing Enter. Unless the tab panel contents may take a long time to load (which generates issues explained in the ARIA Practices Tabs pattern) this is the best experience for users. But if you have implemented tabbing between tabs as well as arrowing this means that you can't get past the tab bar without displaying every tab panel in turn, potentially changing the page content multiple times without any need. This may not be a huge problem but I imagine it could be annoying or disconcerting.

Someone wrote a very interesting article a few years ago based on the results of user testing tab bars and I would recommend you find it if you can and read through it and the subsequent discussion it generated. Their conclusion was that tab bars are an abomination that many users struggle with and we need to rethink them. Their proposals for making them more usable included allowing users to tab between tabs as favoured by Glen. I seem to remember though that they were severely criticised by some prominent members of the accessibility developers community, mostly on the grounds that they were violating established conventions. My memory is a bit hazy so I could be wrong and I need to dig it out and re-read it myself now because I made a mental note at the time to rethink my own opinions on tab bars but never got around to it. I do remember having a lot of sympathy for their position because my background is in usability and user testing and I've found that, aside from fundamental things like buttons and fields with no names, most of the biggest problems users with disabilities and users of assistive technologies face are not WCAG failures. They are to do with understandability, discoverability, complexity, efficiency and the like and are often general usability issues that more acutely affect that user group. A lot of things that work in theory turn out not to work well in practice so I tend to value the findings of user testing very highly.

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Sumit Patel
Sent: Wednesday 19 April 2023 07:39
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] [EXTERNAL] Re: Focus reset

Ok, I appreciate your response.

I have seen testers report this as either a violation or best practice. I meant the scenario where all the tabs are keyboard focusable in a group and they recommend only the selected tab should receive tab focus and able to move around using arrow keys.

whether is it something really to be reported or not?
This is in case these tabs really look like tabs.



On 18/04/2023, glen walker < <EMAIL REMOVED> > wrote:
> The authoring practice patterns are best practices but you don't
> necessarily have to follow them exactly. I rarely say that because I
> think if we all design/code using similar patterns, that makes it
> easier for the user to recognize those patterns on different websites
> and they'll inherently know how to interact with them. In your case,
> you could have the buttons be a vertical tab list, I see those
> occasionally, but you don't have to style them to look like tabs on a
> folder. They could just be a stack of vertical buttons.
>
> And you could implement both arrow key navigation and tab key navigation.
> Yes, the default tab design pattern uses arrow keys to navigate
> between the buttons so that the tab container is one tab stop, but if
> your user testing shows people are more likely to TAB to the different
> buttons, there's nothing that says you can't do both. That would veer
> away from the keyboard interaction pattern a bit but the end goal is
> to make it easy for the user to understand.
>
> On Mon, Apr 17, 2023 at 10:34 PM Sumit Patel
> < <EMAIL REMOVED> >
> wrote:
>
>> Thanks all for your responses. These buttons do not look like tabs.
>> Initially even I thought the same giving "tab" role and associated
>> properties . so, screen reader user will understand contents would
>> have updated below after selection. They will have understanding
>> about the keyboard navigation when they hear "tab" role that they
>> need to use arrow keys if they want to move to other tabs. but, as
>> mark said, sighted keyboard-only user won't have any idea about this
>> as this does not look like a tab. They will be thinking that the
>> other buttons are not keybord focusable.
>>
>>
> > > archives at http://webaim.org/discussion/archives
> >