Browser market share is a useful place to start when deciding which browsers to test a website in. Testing budgets aren’t unlimited, and nobody sensible is arguing that every project should test every page in every browser, on every device, after every change. But, although market share is an important metric, it could be hiding testing risk.
Market share tells us how common a browser is but it doesn’t tell us who is using that browser or why they’re using it. To only look at that metric would keep us ignorant of what users rely on or whether a browser-specific problem could reveal a wider weakness in the build.
I was reminded of this recently while reviewing a website for a client. I found a set of issues that needed attention, and there was interest at first, until I mentioned the browser I was using. The issues were appearing in Firefox.
On the surface, it’s a reasonable commercial instinct
The client contact checked the browser’s market share, Firefox looked small, and the issue suddenly seemed less important to them and to be honest I understood the reaction. On the surface, it’s a reasonable commercial instinct. If a browser represents a small percentage of traffic, it’s tempting to treat the problem as marginal or insignificant in relation to wider business goals.
Something about that decision bothered me, because it moved too quickly from one fact to a conclusion: Firefox has a relatively small share of measured UK browser traffic, therefore this issue probably doesn’t matter. There’s a lot of potential opportunity cost wrapped up in that decision which didn’t get any consideration.
Market share tells you volume, not significance
According to StatCounter, Firefox accounted for 3.42% of measured UK desktop browser traffic in June 2026. Across all platforms, the figure was even lower, at 2.16%. Some figures will quote you up to about 6% if we give the benefit of the doubt.
That data matters. It gives a useful sense of relative usage and helps prevent testing plans from becoming unrealistic. But it’s still only a measure of volume.
The data doesn’t tell you whether the affected users are trying to complete an important journey. It doesn’t tell you whether the browser is more common among a particular audience, and it doesn’t tell you whether the issue affects people using assistive technology.
Market share can tell you that a browser is smaller. It can’t, on its own, tell you that a problem is small.
That distinction matters because website testing isn’t only about chasing the largest percentage. It’s about gaining enough confidence that the important parts of the site work for the people who need them.
Small numbers can hide important users
A percentage can make real people feel abstract. Two or three percent sounds small, but on a site with 20,000 visits a month, 2% is still 400 visits. Whether that matters depends on what those visitors are trying to do.
If the issue is a minor visual difference on a low-value page, it may not justify much, or any, attention. If it blocks a donation, enquiry, booking, checkout, application or support request, the calculation changes.
This is especially true for charities, public-facing organisations and service-based businesses, where the website often carries part of the organisation’s real-world service. A broken form isn’t just a technical blemish. It can mean a lost enquiry, a missed donation, a failed application or a person unable to access important help that affects the quality of their life.
That doesn’t mean every low-share browser issue is urgent. It means the percentage isn’t enough information for us to make our decision. The better question is not just, “How many people use this browser?” It’s, “Who is using this browser, what are those people trying to do, and what happens if they can’t do it?”
Browser choice isn’t always casual
It’s easy to assume people can simply switch browser if something doesn’t work. Sometimes they can. Sometimes they can’t or it would be incredibly disruptive to do so.
People use particular browsers for many reasons: workplace IT policy, older devices, privacy preferences, operating system constraints, development workflows, assistive technology, established habits or simply because changing a setup that works for them creates friction they don’t have capacity for.
Changing a setup creates friction they don’t have capacity for.
None of that means every browser has to be supported equally. But testing decisions should recognise that users don’t arrive as averages. They arrive with real devices, real constraints and real reasons for using the technology they use. Market share masks some of those differences and good testing should put some of them back in.
Firefox is a useful example because it’s technically different
Firefox is not just a smaller browser in the market-share table. It’s also technically useful because it uses a different browser engine.
Chrome and Microsoft Edge are separate browser products, but they’re both based on Chromium and use the Blink rendering engine. Testing both can still be useful as they have different features, integrations, enterprise policies, release decisions and browser-specific bugs.
But testing Chrome and Edge doesn’t give the same breadth of coverage as testing Chrome and Firefox for example. Put simply, Chrome and Edge give you two browser products but testing with Chrome and Firefox gives you two different browser engines. Which sounds more useful to you?
Firefox uses Mozilla’s Gecko engine. That independent implementation can reveal issues that repeated testing inside the Chromium ecosystem may miss. Differences can appear in layout, focus behaviour, keyboard interaction, form controls, newer HTML and CSS features, semantic markup, ARIA support and how information is exposed to assistive technology.
That doesn’t mean Firefox is always the right choice or that only using browsers based on Chromium is always wrong. Different browsers contain unique bugs and display content based upon complicated implementation decisions.
The point is simpler: a different browser engine can show you assumptions you didn’t know you were making. If a site only works because one dominant browser happens to tolerate a fragile implementation, a different engine could be the thing that exposes it.
That makes Firefox or another minority browser useful beyond its market share.
Accessibility is one place where averages can mislead
Accessibility is a good example of why just using aggregate browser popularity can lead to incomplete decisions.
A user’s experience isn’t created by the website alone. It’s created by a chain that includes the website’s HTML, CSS and JavaScript, the browser, the operating system, assistive technology, user settings and the way the person interacts with the page.
A menu might look fine in two browsers but behave differently with keyboard navigation. A custom form control might expose a helpful label in one browser and an ambiguous one in another. An automated accessibility scan might pass while a real screen-reader and browser combination still creates a poor experience.
WebAIM’s 2024 Screen Reader User Survey is useful here, but it needs to be used with care. It would be a crude and incorrect statement to say all those that use accessibility tools use Firefox. They clearly don’t. What it does show is that browser and assistive-technology combinations vary in ways general market-share figures don’t reveal.
WebAIM reported that Chrome was the most common desktop and laptop browser among respondents, but NVDA with Firefox remained one of the common screen-reader and browser combinations. WebAIM also makes clear that the survey is voluntary, international and not a controlled census of all screen-reader users so it’s use may be limited when looking at a specific location such as the UK.
Browser share can miss meaningful differences
The lesson isn’t “Firefox equals accessibility”. It’s that testing decisions based only on general browser share can miss meaningful differences in how people actually experience a site. The browser isn’t passive, it actively shapes the accessibility experience.
The UK Government Service Manual reflects the same broader principle. It recommends testing services with assistive technologies during development and includes browser and assistive-technology combinations such as Firefox with tools including NVDA, JAWS and Dragon.
A commercial website doesn’t necessarily need to reproduce a government service testing matrix. But the principle is useful. Browsers are part of the accessibility environment not just popularity statistics.
A bug you’ve already found changes the question
There’s another important distinction. Planning a testing matrix is not the same as responding to a bug you’ve already found. Before testing begins, market share is a sensible prioritisation tool. It helps decide where most time should go. It keeps scope under control.
But once a real issue has appeared, the browser has already done something valuable: it has already exposed a weakness. At that point, the question shouldn’t only be, “How many people use this browser?” It should also be:
- What journey is affected?
- Does the bug block the user?
- Is there a workaround?
- Could this point to invalid markup, fragile CSS, poor focus handling or brittle JavaScript?
- Does the same component appear elsewhere?
- Could this affect another browser, device or assistive-technology setup differently?
A Firefox bug might turn out to be isolated and low priority. That’s fine. Not every bug deserves the same response and it can then be triaged and assigned the appropriate priority for a fix. But it might also be the first visible sign of a wider problem. It might show that a component has been built too tightly around one browser’s behaviour. It might reveal that a form, menu, modal or third-party widget isn’t as robust as it at first appeared.
That’s why dismissing a discovered issue purely because the browser has low market share is risky. Sometimes the browser isn’t the problem. It’s the canary in the coal mine that can alert us to a defective workflow, design, or build process that could turn into a bigger, more expensive problem further into the project.
The answer is proportionate testing
None of this is an argument for testing everything. I advocate for proportionate testing, enough coverage to give confidence that the important journeys work for the people who need and rely on them.
That starts with the journeys that matter most. For many sites, that means a pretty familiar list:
- contact forms
- checkout
- donations
- bookings
- registrations
- login
- account access
- search
- filtering
- applications and support pages
It also means paying attention to reusable components such as navigation menus, accordions, filters, dialogs, form fields and validation messages which could be reused across many pages. If one of those breaks in a browser, the effect may be wider than it first appears.
A practical testing plan might include the dominant browsers in analytics and at least two different browser engines where practical. For important journeys, it should also include keyboard-only checks, automated accessibility checks, manual testing where risk is higher, testing on real devices as well as software tools and a clear way to triage browser-specific defects.
That doesn’t mean every browser gets equal time. It means the test plan is based on risk, not just popularity.
It also helps to define what “support” means. Does the site need to look identical in every browser? Usually not. Do core journeys need to work, content need to be available, forms need to be usable and users need to avoid being blocked? I feel that’s a more realistic standard.
The clearer the policy, the less likely teams are to make casual decisions in the moment.
Use market share, but don’t hide behind it
Too often, market share gets used as an excuse to avoid fixing a bug rather than understand a problem. A browser looks small on a chart, so the issue is downgraded, deferred or dismissed.
Let’s ask “Which browsers do we need to test so we can be confident that the important parts of this website work for the people who need them?”
Even with this more inclusive approach sometimes when triaging a bug, the answer will still be, “We can live with that.” and that’s fine. Not every defect deserves the same response.
But at least the decision is then based on risk rather than just on reach. And just occasionally, a browser with a small share may show you something much more important than its traffic numbers suggest.
Appendix: links mentioned
- StatCounter, Desktop Browser Market Share United Kingdom: https://gs.statcounter.com/browser-market-share/desktop/united-kingdom
- StatCounter, Browser Market Share United Kingdom: https://gs.statcounter.com/browser-market-share/all/united-kingdom
- WebAIM, Screen Reader User Survey #10 Results: https://webaim.org/projects/screenreadersurvey10/
- WebAIM, Screen Reader User Survey #10 summary: https://webaim.org/blog/screen-reader-user-survey-10-results/
- GOV.UK Service Manual, Testing with assistive technologies: https://www.gov.uk/service-manual/technology/testing-with-assistive-technologies
- Chromium Blink documentation: https://www.chromium.org/blink/
- Mozilla Gecko overview: https://firefox-source-docs.mozilla.org/overview/gecko.html