We QA every WordPress build against a fixed browser and device matrix, a keyboard and screen-reader pass, reduced-motion behavior, and Core Web Vitals budgets — LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 as the good thresholds we design and test toward — before anything is called launch-ready. Cross-browser QA is not a final click-through; it runs from first staging deploy through release, with motion-heavy work treated as highest-risk until proven otherwise. The process below is the same one applied to every Figma to WordPress engagement, derived from the standards in our white-label process guide.
The browser and device matrix
We test where your audience actually browses, then add engines that historically expose layout and stacking differences. The matrix is explicit so “tested” means a named list, not a feeling — and every release runs the same rows unless scope formally changes them.
| Surface | Coverage | What we verify |
|---|---|---|
| Chromium desktop (current and previous) | Chrome / Edge | Layout at design breakpoints, console errors, form flows, extension-resistant behavior |
| WebKit desktop | Safari current on macOS | Viewport and sticky/fixed behavior, font rendering, form controls, hover/focus parity |
| Gecko desktop | Firefox current | Layout edge cases, devtools warnings, scroll and sticky behavior differences |
| iOS | Safari on iPhone (multiple viewport widths) | Safe areas, 100vh-class issues, fixed elements, tap targets, input zoom, motion under real GPUs |
| Android | Chrome on phone | Viewport scaling, keyboard-over-content behavior, scroll performance, mid-tier device checks |
| Tablets | iPad widths; Android tablet where relevant | Breakpoint transitions, navigation patterns, orientation change |
Responsive behavior is verified at the breakpoints defined in design — plus the awkward widths between them, where most layout bugs actually live. Content stress is part of the pass: long headlines, missing images, and late-loading embeds must not collapse columns or spike layout shift.
Keyboard and screen-reader pass
Accessibility QA is a gate, not a backlog item. We tab through every interactive flow in logical order, confirm focus is always visible, and verify there are no keyboard traps — baseline WCAG requirements (keyboard operable, focus visible, no trap) that map directly to how people actually navigate. Menus, modals, carousels, and forms get explicit checks: open, operate, dismiss, and return focus sensibly. Landmarks, labels, alt text, and heading order are reviewed so screen-reader users can parse structure — we verify with screen readers such as VoiceOver and NVDA against the flows that matter: navigation, forms, and primary conversion paths. Skip-to-content, form error messaging, and link purpose in context are standard rows on the checklist, not optional extras discovered during an audit you did not plan for.
Reduced motion: tested, not assumed
Any site with production motion must define what happens when the user prefers less of it. We implement the prefers-reduced-motion media query path and, on GSAP work, use gsap.matchMedia() so timelines attach and detach cleanly instead of being half-disabled with scattered checks. QA confirms three states on affected pages: default motion plays as designed; reduced-motion users get a non-disruptive alternative (instant state changes or minimal fades — no large parallax, no auto-playing sequences that cannot be escaped); and nothing breaks when the preference flips mid-session. This aligns with WCAG guidance on limiting motion from interactions and the pause/stop/hide expectations for moving content. A good reference for the product decision behind the implementation is our prefers-reduced-motion accessibility guide.
Performance budget as a QA gate
We hold builds to Core Web Vitals good thresholds — LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 — measured on representative templates with representative content, not a stripped staging page. The budget is reviewed the same way functional QA is: regressions block release. Images and fonts must be sized and reserved correctly (CLS), interaction handlers must not flood the main thread (INP), and above-the-fold media must stay lean (LCP). Page weight, render-blocking requests, and third-party scripts are on the report your team receives before launch — not a surprise console argument on release day. Motion work is measured under interaction, including scroll-linked sequences, because a sequence that looks fine in a video can still jank on a mid-tier phone.
What fails most in motion work
In our experience, motion is where QA earns its budget. The recurring failure modes: animations that trigger layout on every frame (animating width, top, or large reflows instead of transform/opacity), which shows up as jank and CLS; scroll and pointer handlers doing enough main-thread work to push INP past 200ms on real devices; fixed headers and transition overlays covering content or breaking focus order; motion with no reduced-motion branch shipping “temporary” for months; entrance animations that hide content when JavaScript fails or loads late; and stack-specific differences in sticky/fixed positioning and viewport units between WebKit, Blink, and Gecko — especially inside transformed ancestors. Each of those is caught by the matrix plus vitals gates above, which is why we do not schedule launch before the motion rows are green. Related engineering tradeoffs are covered in what a motion sprint delivers and page transitions vs INP; schedule impact belongs in your timeline and cost planning. When you need capacity behind your own brand, this QA bar ships with our white-label web development work, scoped from our Figma to WordPress process pillar.
Key takeaways
- QA runs against an explicit browser/device matrix, keyboard and screen-reader passes, reduced-motion states, and CWV gates (LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1) — before launch, every release.
- Motion fails most often via layout-thrashing animation, main-thread overload (INP), covered/focus-broken overlays, and missing reduced-motion paths — so motion rows block release until proven green.
Frequently asked questions
Do you test every browser version ever shipped?
No. We test current and previous major versions of the engines your audience uses, plus iOS Safari and Android Chrome where real users live. The matrix is written into the engagement so you know exactly what “QA complete” covers.
Is accessibility testing automated only?
Automated scans catch a subset of issues. Keyboard traversal, focus behavior, screen-reader flows, and reduced-motion outcomes require human checks against real user journeys — automation supplements that pass; it does not replace it.
When in the project does QA start?
From the first staging deploy. Spot checks during build catch template-level issues while they are cheap; the full matrix and vitals gate run before launch as the release decision, not as an afterthought the night before go-live.
How do you handle bugs found the day before launch?
Severity triage with your producer: release blockers get fixed and re-verified in the failing rows; non-blockers get documented with a fix plan and an explicit call on whether they ship. Launch criteria are agreed at kickoff so the call is never improvised under pressure.
Can you QA a site another team built?
Yes — when access and scope allow: staging URL, content parity, and a clear matrix. We report against the same structure above so your client-branded summary is ready for your team to present under your agency’s name.