Aria-practices: How to deal with disabled tabs in an automatically activated tablist

[talimarcus]

According to the WAI-ARIA Authoring Practices, tab elements in a set of tabs should still be focusable when disabled:

For the following composite widget elements, keep them focusable when disabled:

• ...
  
  
  
  • Tab elements in a set of Tabs
  
  
  • ...
  
  

However, this is at odds with the automatic activation pattern of tabs, which automatically displays a tab’s associated tabpanel on focus:

a tab is automatically activated and its associated panel is displayed when the tab receives focus

The problem we're running into is that if a tab is disabled, then its associated tabpanel should not be displayed on focus. This is possible with manually activated tabs, because you can focus on a tab without activating that tab. However with automatically activated tabs, each tab is, by definition, activated upon focus. Pardon the repetition, but this means that in an automatically activated tablist, if we focus on any tab, including a disabled tab, that tab will be activated and its associated tabpanel will be displayed. But the whole point of disabling a tab is to ensure the tab cannot be activated. It seems like the automatic activation pattern is at odds with the guidance to make disabled tabs focusable.

I discussed this a bit with @sh0ji and he said:

I would expect making the tab disabled to disable the automatic activation of the panel, but not focus.

In my opinion, this is a confusing mixing of two paradigms (manual and automatic activation).

The only solution I can think of that doesn't mix the manual/automatic activation paradigms and respects the need to keep all tabs focusable is to still activate a disabled tab on focus, but hide the contents of the associated tab panel somehow. I'd appreciate any other suggestions or guidance on this.

[mcking65]

@talimarcus wrote:

It seems like the automatic activation pattern is at odds with the guidance to make disabled tabs focusable.

Good point; we should add language to the pattern to address this.

I discussed this a bit with @sh0ji and he said:

I would expect making the tab disabled to disable the automatic activation of the panel, but not focus.

In my opinion, this is a confusing mixing of two paradigms (manual and automatic activation).

Perhaps we could clear up the confusion.

If the user moves focus to a disabled tab, the tabpanel content would not change. The currently displayed tab would still have aria-selected true and the tab with focus would have aria-disabled set to true.

The design should clearly indicate that the tab is disabled as well as indicate which tab is selected. So, in this instance, the selection indicator needs to be distinctly different from the focus indicator. In that way it is similar to the manually activated tabs. But, I don't think it confuses the automatic paradigm.

Once focus lands on a tab that is not disabled, then that tab should be selected and displayed.

The reason for keeping the disabled tab focusable is so its presence is more readily perceivable by screen reader users who are operating in the interaction mode, e.g., JAWS forms mode or NVDA focus mode, of their screen reader. If the presence of the disabled tab is not useful information, you could choose not to make it focusable. However, in that case, I would argue that it might be better to hide it completely so that it is not perceived by any user.

The only solution I can think of that doesn't mix the manual/automatic activation paradigms and respects the need to keep all tabs focusable is to still activate a disabled tab on focus, but hide the contents of the associated tab panel somehow.

Displaying an empty tabpanel could be another option, but sounds kind of strange. Maybe another option is a tabpanel that explains why the tab is disabled, e.g., do X to see Y here.

[ZoeBijl]

A look at the documentation shows we have no text at all about disabled tabs. Not in the example, nor the APG, or the ARIA spec.

If it’s advisable to keep disabled tabs in the focus order we should definitely add a note about that.

There’s also nothing about disabled tabs in the code for the code examples. Which as far as I can tell means we currently have no support for disabled tabs whatsoever.

@mcking65 I can fix the code but need to know what happens in certain situations. If you have focus set to the active tab in the tablist and you press right arrow. But the next tab is disabled. Should focus be set to that or the first available non-disabled tab?

[JAWS-test]

I would prefer this variant:

If the user moves focus to a disabled tab, the tabpanel content would not change. The currently displayed tab would still have aria-selected true and the tab with focus would have aria-disabled set to true.

I don't think the following is a good solution:

Displaying an empty tabpanel could be another option, but sounds kind of strange. Maybe another option is a tabpanel that explains why the tab is disabled, e.g., do X to see Y here.

It would mean to show AT users something different than mouse users.

[sh0ji]

I agree that the first variant seems like the best way to handle this. aria-selected is used to convey "activated" and it feels weird/counter-intuitive for activation to not do anything.

I wonder if some of the confusion here comes from the fact that the "automatic activation" pattern ties focus to activation (aria-selected), whereas "manual activation" requires the user to perform two separate actions to focus and activate independently. If we allow the user to focus a disabled tab without selecting it, it's basically functioning like it's the manual activation pattern...but just for that tab. That's confusing if you're thinking of the two patterns as distinct.

And since @talimarcus brought this up the other day, I also started wondered about it in the context of a single-select listbox, where focus also usually follows aria-selected. In that case, I would expect it to function the same way as the disabled tab: the disabled option should still be focusable, but the aria-selected item should remain on the previous option until the user moves to the next one.

In other words, if a user presses the down arrow in a listbox with these three items:

• Apple
• Banana (disabled)
• Orange

The three things that happen should be:

1. select and focus "apple" on the first keypress
2. only focus "banana" on the second keypress (selection stays on "apple")
3. select and focus "orange" on the third keypress

[JAWS-test]

I also started wondered about it in the context of a single-select listbox, where focus also usually follows aria-selected.

Listboxes with the HTML elements select and option skip disabled entries when navigation with arrow keys (in Chrome, Firefox, IE 11...). The question would be whether it makes sense to implement a different behavior for ARIA listboxes.

[ZoeBijl]

Does anyone have an example of a disabled tab out in the wild? Preferably a native UI. I’ve never seen this and would like to do some tests.

Right now I’m inclined to agree with @JAWS-test—disabled controls are usually skipped unless the user lands on them via linear navigation. For tabs I like @mcking65’s suggestion to include them in the arrow navigation to make them more discoverable, too.

1. Ignoring them would be consistent with other patterns (as far as I can tellremember right now).
2. Adding them to the arrow key navigation would make them more discoverable.

[sh0ji]

Our own guidance about when to make disabled controls focusable says that disabled options in a listbox should be focusable. That implies that we want the ARIA behavior to be different from the native widget pattern. I personally think that's a good idea because there's a lot to dislike about <select>.

The four items that we recommend be focusable when disabled are:

• Options in a Listbox
• Menu items in a Menu or menu bar
• Tab elements in a set of Tabs
• Tree items in a Tree View

It'd be good if we either explained why those four patterns are singled out or removed that point entirely. The general guidance seems good enough for authors to make a decision about when discoverability of disabled items is helpful to users.

Either way, the question of _how_ you implement "disabled but focusable" still seems worthwhile even if there are reasons you shouldn't do it most/some of the time.