Some sites now navigate when you hover a menu item, no click required — is that clever or hostile?

It is a real objection, and the core of it is that hover is not an intent signal.

A click says "I want this". A pointer passing over something says nothing at all — the pointer has to cross the screen to get anywhere, and it crosses whatever is in the way. If crossing triggers navigation, then every journey across your menu bar fires actions the user did not ask for.

The browser chrome makes this worse in a specific way you will have felt. Reaching for the address bar, the back button or a browser tab means travelling upward through your navigation. On many layouts that path goes straight across every menu item. So the user reaching for the browser triggers several navigations in your app on the way out.

That is not novelty discomfort. That is the interface acting on movements that were not addressed to it.

There is a version of this that is genuinely good, and it may be what those sites were reaching for: prefetch on hover, navigate on click.

When the pointer lands on a link, start fetching the destination in the background. Do not show anything, do not change the URL, do not commit to anything. If the user then clicks, the page is already there and the navigation feels instantaneous.

You get the entire perceived speed benefit with none of the intent problem, because hover is being used as a prediction rather than a decision. If the prediction is wrong you have wasted a request; if it is right the app feels twice as fast.

This is a well-established technique and it is almost certainly what you want instead.

The accessibility case is even more clear-cut, because hover simply does not exist for a large fraction of users.

• Touch devices have no hover. Whatever you build has to have a tap equivalent, so you are maintaining two interaction models for one control.
• Keyboard users move focus, not a pointer. If navigation happens on hover only, keyboard users get a different app; if you make it happen on focus too, then tabbing through the menu navigates repeatedly, which is far worse.
• Users with motor impairments frequently cannot hold a pointer still. Tremor, an unsteady grip or a head-pointer means the cursor drifts across whatever is nearby. An interface that acts on incidental hover is close to unusable for them.

Hover is fine for revealing information — a submenu, a tooltip, a preview. It is not fine for committing to an action, and navigation is an action.

One more cost that only shows up in testing: hover navigation destroys the ability to explore a menu.

People habitually run the pointer across a navigation bar reading the options before choosing. Under this pattern, reading the menu means visiting every section, and by the time they have looked at the choices they are three pages away from where they started with a polluted history.

That is the behaviour I would watch for if you have any doubt. It is not subtle and it happens within the first minute of anyone using it.