A carousel can match the first Figma frame and still fail after one swipe. The next slide jumps in height, arrows cover translated text, focus disappears when slides become hidden, or autoplay changes the screen before someone finishes reading.
Pixelay can overlay a Figma design on a local, staging, private, or live website and reveal visual drift. For a carousel, comparison must cover a sequence of states and input methods rather than one attractive screenshot.
Define the carousel contract
Write down the intended behavior before comparing pixels:
- number and type of slides;
- fixed or content-driven height;
- one item or multiple items visible;
- finite, looping, or rewind behavior;
- arrows, dots, thumbnails, or pagination labels;
- autoplay timing and pause rules;
- swipe, drag, wheel, keyboard, and button input;
- lazy loading and preloading;
- breakpoint-specific composition;
- reduced-motion behavior.
Compare this list with the Figma states. If the design shows only the first desktop slide, missing mobile, focus, loading, and final-slide states are coverage gaps rather than implementation mismatches.
Make comparison states deterministic
Autoplay and asynchronous images make overlays unstable. In a development or staging environment, use an approved test control to pause autoplay, select a slide by index, and hold transitions at their settled state. Use fixed content fixtures and stable image URLs.
Prepare slides that stress the design: a long title, short title, missing image, portrait image, several cards, translated text, a disabled destination, and the final item in a finite carousel. Avoid production personalization while capturing evidence; two reviewers need to see the same state.
Open the matching Figma frame and browser route at the same viewport, zoom, and content state. Align stable page landmarks before evaluating the carousel itself.
Compare geometry before polish
Use Pixelay’s overlay, split, or difference view to inspect the carousel container, viewport, track, gutters, card widths, image crops, and surrounding page flow. Then check controls and typography.
Pay particular attention to:
- whether partial next-slide previews match the design;
- track padding at the first and last positions;
- card height changes between slides;
- arrows shifting when content height changes;
- pagination alignment with one- and two-digit counts;
- text and buttons clipping inside translated or narrow cards;
- neighboring page content jumping during navigation.
A color mismatch is lower priority than a layout shift that moves the user’s next target.
Review every meaningful state
Capture and compare the first, middle, and last positions. Include hover, keyboard focus, pressed, disabled, loading, image-error, and empty states. For a multi-item carousel, test both full rows and the last incomplete group.
If the carousel loops, inspect the boundary transition in both directions. Duplicate “clone” slides used by some implementations must not become exposed to assistive technology or create a visible jump. If it is finite, the disabled control should look and behave disabled without disappearing in a way that shifts the layout unexpectedly.
For auto-advancing content, verify pause on hover or focus where required, a visible pause control when appropriate, and reduced-motion behavior. Pixelay can prove visible differences; timing and accessibility need interaction testing too.
Test responsive re-composition
Do not scale the desktop judgment down to one mobile width. Compare the breakpoints where the visible item count, card aspect ratio, control placement, or text hierarchy changes. Test just above and below each breakpoint as well as narrow and wide extremes.
On touch devices, verify swipe threshold, vertical-page scrolling, edge behavior, and accidental taps. Controls need adequate hit areas without covering content. Device orientation changes should settle on a valid slide rather than showing a half-positioned track.
The responsive website QA workflow from Figma covers page-wide breakpoint review. Carousel QA adds persistent position, clipped overflow, gestures, and transitions between several content states.
Check keyboard and screen-reader behavior
Use the keyboard to reach visible controls in a logical order. Focus must stay visible, and activating next or previous should not unexpectedly move focus into hidden content. Links and buttons on off-screen slides should not remain reachable when users cannot see them.
Check accessible names for arrows and pagination. “Go to slide 3” is more useful than several controls named only “button.” Decide whether slide changes should be announced and avoid noisy announcements during autoplay. Confirm semantic ordering with a screen reader independently from visual comparison.
Separate evidence by defect type
For visual bugs, record route, environment, viewport, browser, fixture, slide index, Figma frame, comparison mode, screenshot, expected result, and severity. For motion defects, add a short recording and timing details. Track keyboard, touch, performance, and screen-reader problems separately so an overlay screenshot is not treated as complete proof.
Review lazy-loaded slides on a throttled connection. Images should reserve space to prevent layout shifts, loading should not expose blank controls, and a failed image should have a deliberate fallback. Confirm that off-screen media does not create unnecessary page-weight or playback costs.
Sign off the sequence
Before release, compare every structural breakpoint, first and last boundaries, long and missing content, all controls, reduced motion, keyboard navigation, touch gestures, loading, and image failure. Re-test the real production bundle if the staging build differs.
The visual bug report workflow helps turn comparison evidence into actionable tickets. Pixelay makes spatial drift concrete; deterministic fixtures and interaction tests prove that the carousel remains understandable after the first slide moves.
Pro Bundle