A date picker can match its Figma default state and still be badly wrong. The calendar opens in the wrong direction, the selected range loses its middle state, six-week months overflow a modal, or keyboard focus is invisible. Those failures appear only when the team reviews the implemented component as a state machine rather than one screenshot.
Pixelay overlays Figma designs on local, staging, or live web pages so designers and developers can compare the rendered component with its source. For date pickers, the hard part is creating repeatable browser states that make meaningful comparisons possible.
Turn the Figma component into a QA inventory
List every supported mode before testing:
- single date;
- date range;
- month or year selection;
- date and time, if combined;
- inline calendar or popover;
- desktop and mobile presentation.
Then inventory visual states: closed input, empty value, populated value, open calendar, hover, focus, today, selected date, range start, range middle, range end, disabled date, unavailable date, validation error, loading, and read-only.
Do not assume each state exists in Figma. If the implementation supports behavior with no approved design, record it as a design gap rather than forcing it to resemble an unrelated state.
Choose deterministic test dates
“Open the current month” makes screenshots drift every month. Use fixed test dates in a controlled environment so the weekday alignment, month length, and selected range remain stable.
Include months that expose layout problems:
- a 28-day February;
- a leap-year February;
- a month displayed across six calendar rows;
- a range crossing month or year boundaries;
- minimum and maximum allowed dates;
- a daylight-saving boundary if time is involved.
Seed the same dates in Figma and the browser. If the component uses the device timezone or locale, document those settings with the evidence.
Compare geometry before decoration
Open the target page, set the viewport to the matching Figma frame, and use Pixelay to overlay the design. Align to stable page landmarks rather than the popover alone; otherwise a page-level offset can look like a component defect.
Check the large structural questions first:
- input height, label position, and icon alignment;
- popover width and placement;
- calendar grid columns and row spacing;
- header controls and month label;
- safe distance from viewport edges;
- whether the popover is clipped by a container;
- mobile sheet height and scroll behavior.
Then inspect tokens such as type size, border, radius, color, shadow, and spacing. A one-pixel border mismatch matters less than a calendar hidden behind a modal, so triage by user impact.
Walk every interaction state
Overlay comparison is strongest when paired with interaction testing. Use the keyboard to reach the field, open the picker, move between dates, change months, select a range, and close it. Confirm the visible focus indicator matches the intended design and never disappears behind the overlay or browser chrome.
Test pointer and touch behavior separately where relevant. Hover must not be the only cue for an available date. Selected, focused, today, and disabled states need to remain distinguishable when they overlap.
For range selection, inspect the first click, tentative hover range, completed range, reversed selection, and clearing behavior. Check rounded range edges and gaps between week rows. These details often regress because the implementation styles cells individually while the design implies a continuous band.
Test content that changes the component
Localization can alter weekday labels, month names, reading direction, and the first day of the week. Test at least one locale with long month names and any right-to-left locale the product supports. Confirm that navigation icons and range direction behave correctly, not merely that text is translated.
Also test browser zoom, larger text, and narrow viewports. The calendar should remain usable without hiding dates or actions. If mobile uses a bottom sheet instead of a popover, compare it with the correct mobile Figma state rather than scaling the desktop overlay.
The responsive website QA guide provides a broader viewport method; the date-picker pass adds temporal, selection, and locale states that generic page review will miss.
Write bugs with reproducible evidence
For each defect, capture:
- route and environment;
- viewport, browser, locale, and timezone;
- exact test date or range;
- steps to reach the state;
- Figma reference frame;
- overlay screenshot with the mismatch visible;
- expected and actual behavior;
- severity and affected modes.
Separate visual mismatches from functional and accessibility defects. “Focus ring color differs” is visual; “keyboard focus cannot reach the next month control” is functional and accessibility-related. They may share a component, but they need different fixes and acceptance tests.
Release checklist
Before approving the date picker, confirm:
- all supported modes and states were exercised;
- fixed-date fixtures make comparisons repeatable;
- leap years, six-row months, and boundary dates render correctly;
- popovers avoid clipping and viewport overflow;
- selected, today, focus, and disabled states are distinct;
- keyboard and touch paths remain usable;
- supported locales and timezones were tested;
- mobile behavior matches the intended mobile design;
- visual bugs include enough context to reproduce.
This is more specific than a general modal and drawer QA workflow. Date pickers combine overlay geometry with calendar math, locale rules, focus movement, and many overlapping states. Pixelay makes the visual drift obvious; deterministic fixtures and interaction checks make the review trustworthy.
Read as Markdown Related resource index Site index for AI agents
Pro Bundle