Interaction should earn its place.
Movement is most useful when it reveals something the visitor wants to know.
Which question does the interaction answer?
A finish selector on a product page answers “what would this look like in black?” A before-and-after slider answers “how big is the difference?” A process timeline that responds to scrolling answers “what happens after I sign?” Those are good reasons to ask a visitor to interact, because the result is information they wanted.
Compare that with a heading that letters itself in, or a card that tilts on hover. Neither reveals anything new. They can add personality in small doses, but they should never be the only way to reach content, and they should not delay it.
Is the response immediate and obvious?
A control needs a visible consequence, close to where the visitor acted. If someone taps a colour swatch, the product image should change right away, not after a decorative transition. Google’s Interaction to Next Paint metric, one of the Core Web Vitals, treats responses within 200 milliseconds as good; beyond that, interfaces start to feel sluggish.
Keep the link between action and result clear. Label controls with words, not only icons. Show state, such as which option is selected. And make sure the information an interaction reveals is also available as plain text for people and search engines that will never trigger it.
Does it work without hover, motion or a mouse?
Hover does not exist on touchscreens, and many people navigate with a keyboard or assistive technology. The Web Content Accessibility Guidelines require that all functionality be operable from a keyboard, so every interactive element needs a visible focus state and a way to activate it without a pointer.
Motion itself can cause problems. Some people experience dizziness or nausea from large movement on screen, which is why operating systems offer a reduce-motion setting and browsers expose it through the prefers-reduced-motion media query. Respect it: replace sweeping animation with simple fades or instant changes, and keep the page fully usable.
When should motion stop?
Repeated motion competes with the content around it. WCAG’s Pause, Stop, Hide requirement says that moving content which starts automatically and lasts more than five seconds, such as carousels and tickers, needs a way for visitors to pause, stop or hide it. Beyond compliance, it is simply considerate.
Pause animations that are off screen or in a background tab, which also saves battery and processing power. Let looping elements settle once they have made their point. And test the page with every animation switched off: if it still makes sense, the motion is an enhancement rather than a crutch.
How do you decide whether an interaction stays?
Run each interaction through four questions. Does it answer a question a visitor actually has? Does it respond within a fraction of a second? Can it be used with a keyboard and without hover? Does the page still work with motion reduced or disabled? An interaction that passes all four has earned its place. One that fails any of them should be fixed or removed.
Sources and further reading
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2 (opens in a new tab) ↗︎
- W3C: Understanding Success Criterion 2.2.2, Pause, Stop, Hide (opens in a new tab) ↗︎
- W3C: Understanding Success Criterion 2.3.3, Animation from Interactions (opens in a new tab) ↗︎
- MDN Web Docs: prefers-reduced-motion (opens in a new tab) ↗︎
- web.dev: Interaction to Next Paint (INP) (opens in a new tab) ↗︎
Get Field Notes by email
Practical notes on websites, search and automation. A few times a month at most, no fluff, unsubscribe in one click.
About Field Notes →