[Tabs] Activate on click instead of mouse/pointerdown

[mj12albert]

Originally posted by @oliviertassinari in #1318 (comment)

I'm confused. Why does the tab activate on mouse down? I thought this point of using onClick is cancellability. Having to use activateOnFocus to get this behavior feels wrong, this is a different concern.

Examples that activate on click, that is right:

• https://headlessui.com/react/tabs
• https://mui.com/base-ui/react-tabs/
• https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
• https://ariakit.org/components/tab

Examples that activate on pointerdown by default but can be controlled:

• https://react-spectrum.adobe.com/react-aria/Tabs.html but it's controllable with shouldSelectOnPressUp

Examples that activate on pointerdown, that is wrong:

• https://www.radix-ui.com/primitives/docs/components/tabs.

Screen.Recording.2025-01-10.at.23.56.37.mov

But then maybe it's OK if we assume this: applications that have a significant UI state behind tabs must use <a> to trigger the actions. a link triggering on onClick, means it's OK. And then if they don't use a <a>, it means that the state is not that important, so maybe mouseDown is better. I don't really buy that narrative though to be honest, e.g. navigating inside Ashby's UI.

[colmtuite]

Tabs are not modal, and don't take an action that changes the application's state, so there is nothing to cancel. Mousedown feels more responsive.

[oliviertassinari]

@colmtuite "Mousedown feels more responsive", 💯 but the current behavior doesn't seem accessible, not all the time. As I read Success Criterion 2.5.2 Pointer Cancellation

we don't meet this criteria. Now, it's required to pass level A, and enterprise most of the time needs to meet level AA. So I conclude that at the minimum we need a prop to allow to configure this behavior.

I imagine that the root problem is that if the active tab has a state (e.g. an input) and a user mouse down on a tab by mistake, the state of the user gets unmounted and gets lost.

Some examples in the wild

• Humain interface https://developer.apple.com/design/human-interface-guidelines/tab-views

Screen.Recording.2025-01-11.at.19.30.46.mov

• Ashby

Screen.Recording.2025-01-11.at.19.35.00.mov

---

Off-topic. On a different tangent, I see no issue about the story for the disabled state, component: tabs This is the name of the generic UI component, not the React module! , this is important for Material UI users to migrate (it's also a bit more complex as it involves the story around https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/#focusabilityofdisabledcontrols, so e.g. https://ariakit.org/reference/tab#accessiblewhendisabled).
How about we open an issue about this, to get upvotes (to be lazy to better prioritize), to reduce the chances that a developer to open duplicate issues, and for Material UI v7 -> MUI v8 migration tracking?

[colmtuite]

we don't meet this criteria.

That's debatable (as is often the case).

Completing the function on the down-event is essential...Functions that emulate a keyboard or numeric keypad key press are considered essential.

ARIA guidelines recommend that left/right activate the next/previous tab immediately (which is why we enable this by default). Emulating that with mousedown qualifies as "essential" imo.

Humain interface

This example you shared doesn't even have any keyboard a11y, so it's just an inaccessible UI, and not a valid reference.

Ashby

Other tabbed UIs on Ashby activate on mousedown. So again, not a great reference imo. I would guess it's unintentional, and they just haven't yet migrated some parts of their UI to Radix.

Screen.Recording.2025-01-11.at.20.34.33.mov

[oliviertassinari]

That's debatable (as is often the case).

Ok maybe. We can always sleep on this and wait for a11y feedback from community members. We have this issue people can contribute to, and if new strong arguments are made, we can then resume.

---

How I think the WCAG 2.1 spec should be read: they define "essential" as:

if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

https://www.w3.org/TR/WCAG21/#dfn-essential. So to have "essential" as true, we need both to be true:

• using mousedown over mouseup to be imperative. It's often false
• the function to not be possible with another way. It's away false, since we have keyboard.

From there we can conclude that "essential" is always false. And from there we can conclude that in the vast majority of the time, acting on mousedown break this A level rule. Now, because we save something like 100ms by acting on mousedown, and enterprise that are regulated can't use it, I conclude that this behavior needs a prop to control (depending on your use case).

Functions that emulate a keyboard or numeric keypad key press are considered essential.

A tab component isn't a virtual keyboard component, so this note they left seems off-topic, but it's a great example of what an essential use case looks like. We can't build a keyboard virtual component without responding to mousedown.

This example you shared doesn't even have any keyboard a11y, so it's just an inaccessible UI, and not a valid reference.

They have some level of keyboard a11y:

Screen.Recording.2025-01-12.at.12.44.59.mov

[oliviertassinari]

Two more data points:

• For Radix Primitives [Tabs] Tab activates onMouseDown, breaking WCAG 2.5.2: Pointer-cancellation radix-ui/primitives#1879
• For React Aria Support "Pointer Cancellation" (W3C 2.5.2) for useTabList or useTab adobe/react-spectrum#4336. Which they fixed by making the behavior controllable: useTab: adds support for shouldSelectOnPressUp adobe/react-spectrum#4342. I think this passes the good enough bar. I like that it's mousedown by default, so greedy, but if you have state in the tab that can get lost, you can control it with shouldSelectOnPressUp. The main thing missing is a proper ## Accessibility section on their docs to flag this, I also couldn't find the API reference docs for that prop.

Off-topic This makes me think: maybe there is purpose in transfering all Radix Primitives and MUI Base issues to here. All the ones that are still relevant, this way, we could have people upvote them (so we better prioritize) and we would have a clear backlog (instead of community opening duplicates, issues that mixes 3 different things, etc).