Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/WD-14048.

This message was autogenerated

Taking a look at it, it seems the easy fix would be to use tabindex="-1" on the button. As I believe the fix is accessibility-oriented, I would recommend not to use css to account for separation of concerns with the markup.

Here are two questions prior to a PR :

1. Can we expect implementations to include the proper button markup ? In that case, we would rather fix the demos and React implementations.
2. In case we would be looking at a css fix : what would be the accessibility consequences of using display:none on the button instead of the current off-screen utility ? Would the form markup still be valid and accessible ?

I don't believe manipulating the tabindex or display properties of the button are the solutions here. The button is currently correctly accessible/visible on the proper interactions - it's visually hidden until tabbed over, at which point it becomes visible and focused. The real issue is that the button's metrics are simply too large for its container - I think reducing its height, padding, and/or margin would be more appropriate fixes.

The problem is that the form element containing the search input and the hidden search button takes up too much height when the hidden search input is focused. I attempted to solve this by restricting the height of these elements to 100% in PR #5339 .

Triage: this may be high effort fix. This component is used only in React component context, so we should check how it behaves there (not just in static Vanilla docs).

@pastelcyborg: possibly it can be a quick fix (just to make it not break it). Let's timebox them.

Triage: let's try to find a quick fix (max half-day worth of work). If not, leave it for new architecture.