A website proposal that says 'works on all browsers' leaves important questions unanswered. Agree a practical support matrix and test the customer tasks that matter, not only whether the home page looks similar.
Related service: Website and ecommerce development- 01Identify the audience
- 02Choose representative environments
- 03Run important journeys
- 04Record defects
- 05Retest the release
SECTION 01
Define support in terms of usable tasks
List the important journeys: understanding the offer, using navigation, submitting an inquiry, downloading a resource, or completing the store's supported purchase flow. Then identify browser families, operating systems, screen sizes, and input methods relevant to those tasks. Use available audience data carefully; a new site may need reasoned assumptions rather than invented usage statistics.
MDN's cross-browser testing guidance recommends a considered target audience and testing approach. W3C's page-structure guidance supports meaningful content across user agents. Ask the agency to record the support matrix and how it will be reviewed. A statement about identical pixels everywhere is less useful than evidence that the task remains understandable and functional.
SECTION 02
Illustrative example: a mobile form hidden by the keyboard
Imagine a visitor opens a quotation form on a phone. The page fits the narrow viewport, but opening the software keyboard covers the active field and submit control. A desktop browser resized to phone width did not reproduce the problem. The issue affects completion, not merely visual polish.
The test plan includes the relevant mobile environment, form focus, scrolling, and error correction. The developer records the failure, fixes the layout behavior, and reruns the same task. This example is illustrative. It shows why a screenshot collection and an automated build are evidence of different things, neither of which alone proves the complete mobile journey.
SECTION 03
Set a clear defect and acceptance process
Ask for reproducible defect records containing the page, environment, steps, observed result, and expected behavior. Prioritize broken tasks, lost data, inaccessible controls, and misleading states before minor rendering differences. Decide how unsupported older environments are handled and whether visitors receive a usable fallback.
Acceptance should include regression checks after fixes, representative slow-loading conditions, long content, and third-party components. Keep a record of what was tested and what remains unverified. The tradeoff is coverage versus effort: choose a defensible matrix and expand it when real evidence shows a gap. At handoff, name who reviews new browser releases or customer-reported failures so support does not end with an outdated launch checklist.
SECTION 04
Frequently asked questions
Can automated tests replace manual browser review?
They can cover repeatable behavior, but hands-on checks still reveal interaction, layout, and device-specific problems.
Must every browser look exactly the same?
Not necessarily. The agreed content and tasks should remain usable; some visual differences may be acceptable.
What proves that a bug is fixed?
Reproduce the original scenario after the change, verify the expected result, and check related journeys for regressions.
PRIMARY REFERENCES
Sources and further reading
These references cover the standards, platforms, or published prices discussed in the guide. Worked examples and checklists are our editorial guidance.
- Introduction to cross-browser testingMDN Web Docs
- Page Structure TutorialW3C WAI
EDITORIAL METHOD
About this guide
We use AI to assist with drafting and editing. Catapult AI Work is responsible for the published content. Examples illustrate possible approaches; they are not client case studies unless identified as such.
Budget examples are not Catapult package prices. Check linked provider pages for current fees and plan limits before making a purchase.
Read the editorial policy