A dropdown menu opens fine when you hover over it on your laptop. You approve the page. Two weeks later, a customer says the menu “does nothing” on their phone — because there’s no mouse on a phone, and the menu was built to open on hover. Nobody lied to you. The screenshot you reviewed just couldn’t show you a state that only exists mid-interaction.

This is a structural gap in how most website reviews happen, not a one-off mistake. Screenshot feedback — the default review method for most small teams — captures a page exactly as it renders at the moment the image is taken. That’s one input state, one scroll position, one moment in time. Hover menus, focus rings, loading spinners, and scroll-triggered animations don’t exist in that frame. They exist only while a cursor, a keyboard, or a scroll event is actively triggering them. A reviewer working from screenshots alone is reviewing a page with an entire category of behavior invisible by design.

Why can’t a screenshot capture an animation or a hover state?

Because a screenshot is a single frozen render, and hover, focus, and animation states only exist while something is actively triggering them. The moment the trigger stops — the mouse moves away, the scroll stops, the page finishes loading — the state reverts, and a static image taken before or after that window shows the default state instead.

This isn’t a limitation of any particular tool; it’s how CSS itself defines these states. The CSS hover media feature exists specifically because not every device can even trigger a hover state in the first place — touch devices have “the primary input mechanism [that] cannot hover at all or cannot conveniently hover,” per MDN’s own definition. A screenshot taken on a desktop browser shows you a hover-capable rendering; it says nothing about what a touch visitor — the majority of your traffic — will actually experience, because touch has no equivalent trigger to begin with.

What interaction bugs slip through a screenshot-only review?

Four categories, and all four are invisible in a static image:

Hover-only navigation. Dropdown menus, tooltips, and secondary nav items that only appear on :hover don’t just look different on touch — they may not be reachable at all, since touch has no convenient hover equivalent to trigger them.
Missing or broken focus indicators. A keyboard user tabbing through the page needs to see which element currently has focus. The W3C’s Success Criterion 2.4.7 (Focus Visible) is direct about why: “Without a focus indicator, sighted keyboard users cannot operate the page.” A screenshot of the page at rest shows nothing about whether focus is visible, because focus is a state, not a layout.
Scroll- and interaction-triggered animations. Elements that fade in, slide, or move when triggered by scroll position or a click never appear in a still image at all — you’d have to happen to screenshot mid-animation, which nobody does.
Loading and transition states. Spinners, skeleton screens, and in-between states while content swaps out are, by definition, temporary. A screenshot taken a second before or after shows only the before-and-after, never the transition.

None of these are exotic edge cases. Nielsen Norman Group defines microinteractions — the category that covers all four — as pairs where “the trigger can be a user action or an alteration in the system’s state” and “the feedback is a narrowly targeted response to the trigger.” By NN/g’s own framing, microinteractions exist specifically to communicate system status, prevent errors, and reinforce the interface — which means a review that never sees them is a review that’s missing exactly the moments a page is trying hardest to talk to the user.

How do you review hover states, focus states, and animations without owning ten devices?

Run a structured four-part pass instead of trying to catch these states by accident during a normal click-through.

Does every interactive element get a visible focus ring when you tab to it?

Put the mouse down and tab through the page with only the keyboard. Every link, button, and form field should get a visible outline or highlight the moment it receives focus — if you can’t tell where you are on the page without looking at the cursor, that’s the bug. This single pass catches the most common accessibility gap on small-team sites: developers frequently strip the default focus outline for aesthetic reasons and forget to replace it, and Chrome DevTools’ focus-tracking guide exists precisely because focus rings “sometimes disappear because the element that has focus is hidden” — which is invisible in any screenshot, since a screenshot never shows keyboard state.

Does every hoverable element behave the way it looks like it should?

Move the mouse over every button, card, nav item, and link — not just the obvious ones. Watch for menus that open, tooltips that appear, cards that lift, and buttons that change color. Then ask the harder question: does anything important only happen on hover, with no equivalent for someone who can’t hover at all? If a dropdown only opens via :hover with no click fallback, that’s a bug for the majority of your visitors, not a stylistic choice — touch devices “emulate hovering” at best, per MDN, through an “inconvenient long tap” that most users will never discover.

Can you inspect a hover or focus state without holding your mouse perfectly still?

Yes — and you should, because trying to screenshot a hover state by holding the cursor steady is unreliable and slow. Right-click the element in your browser’s DevTools and use Force element state (Chrome calls this triggering a pseudo-class) to lock in :hover, :focus, or :active. The state stays visible even after you move the mouse away, which means you can actually inspect the styling, take a clean screenshot of it, or point a teammate to the exact same locked state instead of describing something that vanished the moment you let go of the mouse.

Do scroll-triggered and click-triggered animations play the way they’re supposed to?

Trigger each one deliberately and watch it start to finish, at normal speed, rather than glancing at the before-and-after. Pay attention to whether the animation respects a user’s motion preferences — the prefers-reduced-motion media query exists because, in Google’s own framing, some users experience real physical symptoms from unnecessary motion: “vestibular (inner ear) disorder reactions include dizziness, nausea, and migraine headaches.” The W3C’s guidance on animation from interactions is equally direct that this isn’t a preference issue but a functional one for some users, since “scrolling a page [that] causes elements to move… can trigger vestibular disorders.” A review pass that never triggers the animation on purpose will never catch a missing reduced-motion fallback.

How do you write feedback on a state that will have already reverted by the time your developer reads it?

Name the trigger, the expected result, and the actual result — in that order, every time. “The hover menu is broken” describes nothing a developer can act on, because by the time they read it, the hover state is gone and there’s nothing left to compare against. “Hovering the ‘Services’ nav item should open a dropdown with four links; instead nothing happens” gives a developer an action to repeat and a specific outcome to check for. This is the same visual feedback precision that matters for static layout bugs, just applied to a state that only exists for as long as the trigger is active.

The harder problem is that by the time you’ve finished typing that sentence, the state you’re describing from memory has already reset — you’re reconstructing it, not looking at it. This is where reviewing from a live page beats reviewing from a static image or a written description of one. Simpl_Markup’s live, interactive preview of the page lets you navigate to the actual page, trigger the hover or animation yourself, and drop a pin while the state is still on screen — Simpl_Markup captures the exact URL, viewport, scroll position, and element coordinates at the moment you click, so the comment is anchored to what you were actually looking at rather than what you remember seeing. Static device screenshots still generate automatically for every project and still post to Slack for the layout-level pass — the two aren’t a replacement for each other, they’re suited to different bugs. Screenshots are enough for “this button is the wrong color.” A hover menu or a scroll animation needs the state captured live, because there’s nothing to screenshot until it’s actually happening.

What’s the fastest way to fold this into a review you’re already doing?

Add it as a fifth pass, not a separate review. If you’re already running a pre-launch checklist across desktop, mobile, and tablet, tack the four-part interaction pass onto the end: tab through with the keyboard, hover everything, force a state or two in DevTools if something looks off, and trigger every animation on purpose instead of glancing past it. It adds ten to fifteen minutes to a review that’s already happening. What it saves is the two-week gap between “we approved this” and a customer reporting a menu that “does nothing” — because the bug was never invisible. It just wasn’t in the frame.