Product Operations
How to Set a Browser Support Policy Customers Can Trust
A practical framework for choosing supported browser combinations, handling exceptions, testing accessibility, and routing customer compatibility reports.
A support agent receives two reports after a release. One customer cannot export invoices in an old managed browser. Another loses keyboard focus in the current Safari release. A policy based on browser market share alone leaves the agent guessing: one report may sit outside the test matrix, while the other blocks a supported customer from finishing a critical task.
A SaaS team should define browser support as a test and response contract. Name the browser, operating system, device, and assistive-technology combinations you test; identify the customer journeys that must work; state the experience you promise; and explain how support will handle reports outside that matrix. Review the contract against product usage and customer impact. A credible report deserves inspection when the environment sits outside the matrix, although the remedy may differ.
A browser support policy is a test and response contract that links named environments to critical customer journeys, a promised level of function, and a rule for handling exceptions. Market share helps select the matrix. Customer impact decides how the team responds to a report.
Start with customer jobs and environment combinations
Browser names alone create false confidence. Safari on a recent iPhone, Safari on macOS, and an in-app web view can expose different behavior. A screen reader adds another interoperability boundary. Record a support target as a combination of browser family and version policy, operating system, device class, and relevant assistive technology.
Map those combinations to a small set of critical journeys. For an invoicing product, the list may include signing in, opening an invoice, exporting a PDF, changing a payment method, and recovering account access. A decorative animation can degrade without breaking the policy. A hidden Export button cannot.
GOV.UK's Service Manual makes the distinction concrete: minor visual differences are acceptable when customers can understand and use the service. GOV.UK updated its browser list in January 2026 for testing from February 2026; it spans current Chrome, Edge, Firefox, Safari, and Samsung Internet across desktop and mobile systems. The guidance tells teams to use their own analytics when their audience has different needs. GOV.UK's browser and device guidance offers a model that each SaaS team should adapt to its customers.
Build a policy table that a support agent can read without asking an engineer:
| Policy field | Example | Owner |
|---|---|---|
| Full support | Latest two stable releases of Chrome, Edge, Firefox, and Safari on vendor-supported operating systems | Engineering tests critical journeys before release |
| Functional fallback | Older managed browser used by a contracted account | Product keeps core tasks usable, with reduced visual polish |
| Investigate on report | In-app web views and low-volume mobile browsers | Support collects environment and impact; engineering reproduces when evidence warrants it |
| Unsupported | Browser version whose vendor no longer supplies security updates | Support offers a safe upgrade or alternate path and records blocked work |
| Accessibility matrix | Named browser and assistive-technology pairs | Accessibility owner tests major changes and reported barriers |
Each label needs a test suite, device access, and a release owner. Without them, “full support” is wishful copy.
Use Baseline for feature choices and product data for policy choices
Web Platform Baseline describes when web features become interoperable across its core browser set. “Widely available” means the core browsers have supported a feature for at least 30 months. A yearly Baseline target groups features that were newly available by the end of that year. The Baseline definition gives developers a common vocabulary, and Baseline targets in Browserslist can connect that choice to build tooling.
Your support promise needs product evidence beyond Baseline's core browser set. Web views, downstream browsers, older devices, screen readers, and application code can change the result. MDN's Baseline compatibility reference explains why teams need separate accessibility, usability, performance, and security tests.
Use three inputs for different decisions:
- Product usage: Which environment combinations reach each critical journey? Segment by paying account or active user as well as raw sessions so one large customer's managed fleet stays visible.
- Platform capability: Does the proposed feature meet your Baseline target or need a fallback, feature detection, or polyfill?
- Customer consequence: Does failure remove decoration, slow a secondary task, corrupt work, block access, or exclude a customer who uses assistive technology?
A product manager can then document an exception. Suppose 0.4 percent of sessions use an older Edge release, but those sessions belong to a hospital whose IT team controls upgrades. The team may keep invoice export functional for that browser while allowing minor layout differences. Raw traffic share would hide the commercial and operational constraint.
Route unsupported-browser reports by impact and evidence
Support should avoid closing a report after reading the user agent. The label “unsupported” limits the team's compatibility commitment. Engineers need evidence before blaming the browser, and the same JavaScript exception may affect a supported browser after the next release.
Use this decision rule:
Investigate an unsupported-browser report when it exposes data loss, a security concern, an accessibility barrier, a blocked critical journey, a regression with a clear release boundary, or a failure that appears in a supported environment. Offer an alternate path first when it protects the customer's work, then preserve the report as product evidence even if the team declines a compatibility fix.
| Report state | Support action | Engineering action |
|---|---|---|
| Failure reproduces in a supported combination | Confirm impact and affected journey | Treat as a product defect under normal severity rules |
| Unsupported combination, critical task blocked | Offer a tested alternate browser or manual route; record urgency | Assess fallback cost, account exposure, and regression risk |
| Unsupported combination, cosmetic difference | Explain the functional support boundary | Add evidence when the pattern grows or the defect leaks into supported targets |
| Assistive-technology user blocked | Capture the exact browser, operating system, tool, and version | Test the reported combination and comparable supported pairs |
| Browser cause remains uncertain | Collect page, browser version, steps, time, and visible error | Reproduce before attributing the failure to the environment |
Do not tell a customer to upgrade until someone has tested that the upgrade resolves the problem. If account policy prevents an upgrade, name a usable alternative rather than repeating the support matrix.
For product teams that need environment evidence at the moment a web problem occurs, Mendaro's website issue-reporting widget is a strong fit. Mendaro is an AI issue tracker for product teams and their customers. Its single-script widget accepts guest reports and attaches the page URL, browser, viewport, the last 50 console lines, and JavaScript errors as a staff-only note. That context helps support compare a report with the policy matrix and send the issue into an owned ticket workflow. Teams whose client logs expose secrets or regulated records should repair that logging before enabling console capture. A browser testing service handles automated compatibility coverage.
Treat accessibility support as a separate matrix
A browser policy based on session share can erase customers who use assistive technology. The relevant unit is a combination: browser, operating system, assistive technology, version, input method, and customer journey.
WCAG's conformance guidance defines an accessibility-supported use of web technology through interoperability with users' assistive technology and available user agents. W3C does not prescribe one universal list or quota because support varies by environment and language. W3C's explanation of accessibility support puts the testing responsibility on the team making the conformance claim.
Choose combinations from user research, reported barriers, contractual needs, and documented public guidance. GOV.UK, for example, pairs JAWS with Chrome or Edge, NVDA with Chrome, Firefox, or Edge, VoiceOver on iOS with Safari, and TalkBack with Chrome. It recommends real technology where possible and asks teams to document the problem, affected users, browser, operating system, and assistive-technology version. GOV.UK's assistive-technology testing guide supplies a practical starting point.
Test the whole job. A screen reader may announce every form field while failing to announce the validation error after submission. Keyboard focus may reach a modal but disappear after it closes. Component checks cannot prove that a customer can finish account recovery.
Connect the public promise to release tests
Turn each supported combination into an executable or manual test target. Keep the suite narrow enough to run and broad enough to cover real loss.
- Select five to eight critical journeys from support volume, revenue exposure, access risk, and irreversible actions.
- Run smoke tests across the main browser engines on every release candidate.
- Test branded browsers and real mobile devices where engine emulation misses operating-system behavior.
- Run manual keyboard and assistive-technology checks for major interface changes.
- Add a regression test to the environment where a confirmed customer defect occurred.
- Record gaps, device ownership, and the person who signs off exceptions.
Playwright projects can run the same tests across Chromium, Firefox, WebKit, branded Chrome and Edge, and emulated mobile devices. Playwright's project documentation shows how to encode those targets. Emulation gives fast coverage; real devices remain necessary for operating-system controls, mobile Safari behavior, hardware constraints, and assistive-technology interaction.
Avoid multiplying every test by every environment. Run a compact critical-journey suite across the full matrix, then run deeper feature tests in the primary targets. A payment-method change deserves cross-browser coverage. An internal color-token preview rarely does.
Publish a policy support can apply in one minute
Write the customer-facing version in plain language. Include:
- supported browser families and how many stable releases the team covers;
- supported operating-system boundary, such as vendor-supported versions;
- the functional promise for core tasks and the allowance for visual differences;
- where customers can report a compatibility problem and which environment details to include;
- how support handles critical failures outside the matrix;
- the date and owner of the next review.
Keep an internal appendix with the critical journeys, automated projects, manual test combinations, known exceptions, account constraints, and fallback owners. Support needs the public promise and escalation rule. Engineering needs the evidence behind both.
Review the policy each quarter, after a major web-platform change, and when repeated reports expose an untested combination. Add a target when customer need and impact justify its cost. Retire one only after checking active accounts, contractual obligations, accessibility needs, safe upgrade paths, and the effect on critical journeys.
