Border radius control: incorrect usage of Tooltip causes unexpected tab stop

[afercia]

Description

Discovered while testing #68498

This is one more occurrence of incorrect usage of the Tooltip component. Cc @WordPress/gutenberg-components

The Ariakit-based Tooltip adds a tabindex=0 attribute to the DOM element it wraps. When the wrapped DOM element happens to be an element that is supposed to be focusable that't not a big deal. However, when the wrapped element is just a DIV element, it becomes a focusable non-interactive, non-labeled element. This isn't OK and among other things it causes an unexpected tab stop when using the keuboard.

gutenberg/packages/block-editor/src/components/border-radius-control/input-controls.js

Lines 71 to 86 in ddfbdcc

	<Tooltip text={ label } placement="top" key={ corner }>
	<div className="components-border-radius-control__tooltip-wrapper">
	<UnitControl
	{ ...props }
	aria-label={ label }
	value={ [ parsedQuantity, computedUnit ].join(
	''
	) }
	onChange={ createHandleOnChange( corner ) }
	onUnitChange={ createHandleOnUnitChange(
	corner
	) }
	size="__unstable-large"
	/>
	</div>
	</Tooltip>

In this case, the element with CSS class components-border-radius-control__tooltip-wrapper gets a tabindex=0. As such, tabbing through the UI requires an additional, unexpected, Tab press on an element that isn't interactive just to make hte Tooltip appear.

Animated GIF:

Step-by-step reproduction instructions

• Select a Group block.
• Go to the block settings panel > Styles > Radius setting and click the 'Unlink radii' icon button to switch the control to the UI that renders 4 input fields.
• Use the Tab key to navigate through the four input fields.
• Observe you have to Tab three times for each input:
  1. FIrst tab stop: the focusable DIV with tabindex=0
  2. Second tab stop: the actual input field
  3. Third tab stop: The 'Select unit' select element.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Rishit30G]

Thanks for sharing the issue,
I could replicate the issue on my local
So as per my understanding if we remove the div and add the class to the UnitControl Component, we can get proper tab navigation

<Tooltip text={ label } placement="top" key={ corner }>
     <UnitControl
		{ ...props }
		aria-label={ label }
		value={ [ parsedQuantity, computedUnit ].join('') }
		onChange={ createHandleOnChange( corner ) }
		onUnitChange={ createHandleOnUnitChange( corner ) }
	         size="__unstable-large"
		className="components-border-radius-control__tooltip-wrapper"
	/>
</Tooltip>

Before:

Screen.Recording.2025-01-10.at.3.52.15.PM.mov

After:

Screen.Recording.2025-01-10.at.3.45.41.PM.mov

[yogeshbhutkar]

I think we can pass the classname to Tooltip component directly as Unit Control is indeed what is getting wrapped here.

Edit: Looks like the classname isn't used anywhere.

[afercia]

I think this should be fixed by removing the Tooltip component, set the key to the wrapepr and change aria-label to label on the UnitControl.

This would make the input field labels visible. As such, some design adjustments may be neeed but input fields are really not supposed to have tooltips.

My guess is that the current, incorrect, implementation was only done to hide the labels and use tooltips for the input fields. That's not great for accessibility.