Small browser share, big impact: Why “small %” is the wrong mindset

Written by

Paul Edwards

in

,
Small browser share, big impact: Why “small %” is the wrong mindset
Small browser share, big impact: Why “small %” is the wrong mindset
0:00
–:–

It’s “only 2–3% of users” … until you realise it’s a conversion leak

I had a conversation recently with someone who’d built a brand new website for a charitable organisation. It was genuinely well done: a strong value proposition, carefully structured, and persuasive without being over the top.

I mentioned that there were some layout issues in one particular browser. The response was basically: we’re not bothered, that browser barely has any market share.

We’re not bothered, that browser barely has any market share.

And to be clear, I’m sure that it was said with a bit of tongue‑in‑cheek humour. But it hung around in the back of my mind for days and caused some irritation, because it’s exactly the kind of logic that lets exclusion creep in unnoticed.

Because I’ve heard that mindset before. We used to talk about accessibility the same way: it’s only a small percentage of people, so it’s fine if they struggle. And we now (rightly) recognise how wrong that is.

With accessibility, the exclusion is created at the website end: if you build something that a group of people can’t use, you’ve effectively locked them out. With charities, that can land as a very real outcome: fewer people able to donate or sign up, which ultimately means fewer resources available to help the people you’re here for.

A browser isn’t the same thing as a disability, of course. But the logic is very similar: it’s acceptable to exclude a small group if fixing it is inconvenient. That’s not a technical decision. It’s an inclusion decision.

It’s only a small percentage of people…

Quick take (what I’d actually do):

  • Write down a supported browsers policy (and what “supported” means)
  • Define 3–5 “core journeys” (donate, sign-up, contact, etc.) and test them after every change
  • If someone reports a browser-specific issue: treat it like a conversion leak until proven otherwise
  • Keep scope bounded: support the browsers your audience uses, and agree what happens outside that baseline

A small percentage is still real people (and real outcomes)

The problem with percent-thinking is it hides the human reality.

If your site gets 20,000 visits a month, 2% is 400 people. If the broken journey is “Donate”, “Volunteer”, “Get help”, “Report a safeguarding concern”, “Request support”, or even “Read the impact report”, that’s not a rounding error. That’s mission impact; it’s real lives affected.

And even if the absolute number is small, the message it sends is big: “You’re not worth designing for.” For a charity, that can be brutal when the entire brand is built on care, inclusion, and trust.

Your entire brand is built on care, inclusion, and trust.

“Browser support” is actually a values decision

When a site fails on one browser, teams often treat it like a niche bug. Something to ignore, or to park for later.

But browser compatibility is one of the practical ways we deliver on a basic promise: the service works for people where they are.

That’s close to the heart of what accessibility is, in the broad sense. W3C put it plainly: “Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services.”

Notice the framing: not “compliance”, not “nice to have”. Not excluding people.

So when someone says “we don’t care about that browser”, they’re saying: “We’ve decided those users can be excluded.”

That might still be a decision you make sometimes. Every team has finite time and money. But if you do make it, it should be a conscious decision, agreed by the organisation, and backed by a policy. Not shrugged off in a dev chat.

This is uncomfortably close to the old accessibility mistake

The web accessibility world has spent years trying to undo the damage caused by “edge cases don’t matter” thinking. And the data shows we still have a long way to go.

WebAIM’s 2026 analysis of the top 1,000,000 home pages found that:

  • 95.9% of home pages had detectable WCAG conformance failures
  • Across the sample, there were 56.1 detected accessibility errors per page on average
  • “Low contrast text” alone appeared on 83.9% of home pages

The point isn’t “everything is terrible”. The point is: exclusion happens easily and at scale, even when nobody intended it.

Exclusion happens easily and at scale.

Now add browser incompatibility on top and you end up excluding people twice: once because the interface isn’t accessible, and again because it doesn’t even run reliably in their browser and device setup.

Why this matters more for charities (and public-serving organisations)

As a broad generalisation, charities don’t run websites for entertainment. Websites are often part of the service they deliver.

And because charity sites rely on people completing actions (donating, signing up, enquiring, downloading resources), small amounts of extra friction can have an significant impact on conversion rates. If a journey fails outright in a particular browser, it’s not just “some users had a worse experience”, it’s lost donations, lost sign-ups, and less support reaching the people who need it.

If you’re running paid campaigns, it can also contaminate your conversion data: you end up optimising budgets and ads based on partial, misleading signals.

If someone reports “it’s broken in my browser”:

  • Confirm which journey is affected (donate, form, checkout, etc.)
  • Reproduce it (or at least capture a screen recording + exact steps)
  • Test the same journey in 1–2 other browsers/devices (to separate “browser-specific” from “site-wide”)
  • Decide severity: if it blocks a core journey, treat it as urgent
  • Log it and fix it in the simplest safe way (then re-test the core journeys)

When a charity website breaks, people can lose:

  • the ability to donate
  • the ability to find and access support
  • the ability to access information quickly in a moment of need
  • confidence that the organisation is competent and trustworthy

And it’s worth remembering: people don’t choose browsers in a vacuum. Sometimes they’re locked in by:

  • workplace IT policy (you get what you’re given)
  • older devices that can’t be upgraded
  • privacy preferences
  • accessibility tooling and established setups

Telling someone “just use another browser” or assuming they can use another browser, is like telling someone “just use another staircase”.

Again, not identical. But the same instinct to shift the burden onto the user.

The practical middle ground: a browser support policy

None of this means you have to support everything forever. What you need is a simple, written stance that answers three questions:

  1. Which browsers and versions do we support?
  2. What does “support” mean? (Fully functional? “Core journeys work”? “Looks identical”?)
  3. What happens when we find an issue outside the support baseline? (Severity rules, response times, workarounds)

This matters because it turns the conversation from “I don’t care” into “Here’s our policy, here’s why it’s reasonable, and here’s how we handle exceptions”.

It also keeps scope bounded and costs predictable, because you’re agreeing expectations up front instead of arguing about them after something breaks.

A useful reference point is the GOV.UK Service Manual guidance on designing for different browsers and devices. It sets the expectation that a service must be universally accessible and that you should test based on real user analytics, while recognising that “some users may access your service using older or unsupported browsers” and you may decide whether additional support is needed.

(If you’ve never read GOV.UK’s service guidance, it’s one of the most practical, grounded bodies of guidance on building digital services for real people.)

How to test without going broke

Most cross-browser issues don’t need heroics or huge investment to vis them. They need consistent application of coding standards, naming conventions, mobile first design and graceful degredation where a browser doesnt support certain CSS.

Here’s a simple approach I recommend for charities and small teams:

  • Define your core journeys (donate, contact, sign-up, find help, apply, book)
  • Pick a small browser set for each release (based on your analytics, plus at least one “non-default” browser)
  • Test with keyboard only for those journeys (it catches a lot fast)
  • Add a regression checklist before each deployment
  • Treat forms as sacred: labels, validation, error messages, and submit states should always work
  • Don’t just test different screen sizes and aspect ratios in the browser as simulations, actually use a handful of real devices running on different operating systems and browsers.

If you want to go deeper on what “accessible enough” even means, WCAG 2.2 is the current W3C recommendation and it’s clear about the breadth of needs it covers, from low vision to limited movement to cognitive limitations.

Most cross-browser issues don’t need heroics. They need consistency.

And if you want a powerful reminder of why this matters, W3C’s own accessibility video includes this line: “There are over one billion people with disabilities, or about 15–20% of the population … implementing the accessibility standards is essential for people with disabilities, and useful for all.”

What to do when the bug is “only in one browser”

When you hit a browser-specific issue, you want to avoid two extremes:

  • “We must fix this perfectly right now no matter what”
  • “Meh, ignore it”

Instead, triage it like a grown-up:

  1. Is it breaking a core journey? If yes, treat it as high priority.
  2. Is there an accessible workaround? If no, increase severity.
  3. Is the affected group identifiable and meaningful? (It often is.)
  4. Is this a one-off, or does it point to a pattern? (Modern JS tooling, polyfills, CSS support assumptions, third-party embeds, cookie banners, donation widgets.)

Then fix it in the simplest safe way. Often that means:

  • removing or rewriting a brittle JS feature
  • improving progressive enhancement
  • swapping a third-party embed for something more robust
  • adding a polyfill or build step you thought you didn’t need

None of that is glamorous. It’s maintenance work. And maintenance is where reliability and inclusion actually get delivered.

Bottom line

If a browser is only used by 2–3% of your audience, you can still decide whether you will or wont support it or to what extent, but pretending it doesn’t matter, that’s a problem.

Pretending it doesn’t matter is the problem.

Because that’s not a browser decision. It’s a decision about who gets access to your service and who doesn’t. If you’re building for charities, I think you should treat that as a values issue first, and a technical issue second.

If you want this handled quietly and properly

If you’re a charity or a small team running a WordPress site, a big part of what you’re paying for in a website maintenance agreement is this: someone who will take these issues seriously, define sensible standards, test the right things, and fix problems before they become public, stressful, or expensive.

That’s what I do as a continuity partner, not just a “when it breaks” developer. Feel free to give me a call on 01903 527927 or via my contact page and we can discuss your situation in more depth.

Appendix: links mentioned