Make the Web Work For Everyone

Updated 2016/07/22: Commenters found a few data errors (thanks!) which have now been corrected.

Millions of websites have compatibility problems on one or more of the major browsers, leading to a poor user experience. The web developer community can fix this.

The web has changed immensely in the past 20 years. In 1996 there were roughly a million websites; now there are more than a billion. Back then there were roughly 50 million internet users; today there are more than 3 billion. We have more content than we ever dreamed was possible. People are enjoying it on 8.1 billion connected devices, including more than 24,000 distinct mobile device types.

Statistics illustrating explosive growth in the number of sites, users, and devices.

This explosive growth in content, devices and users has made cross browser compatibility even more essential than it was in 1996. Stack Overflow has almost 55,000 questions that include the string “cross-browser”, and hundreds of thousands of questions about things that work fine in [Browser X]. Any question about how a particular browser handles a particular site is a potential compatibility question.

Statistics showing the number of questions on Stack Overflow that relate to cross-browser compatibility.

So yeah, cross-browser compatibility is still a thing. It’s a thing we care about at Mozilla, and we think you should care about it too. Why? Well, your users probably aren’t on the same browser as you. They have different abilities and needs than you think. They won’t change browsers if your site breaks for them. Serving them well is one way to demonstrate mastery of your craft. And modern tools make it easier than ever.

What causes cross-browser incompatibilities? It’s complex. Here are some of today’s top culprits:

  • Developers who use browser-specific features (e.g. vendor-specific prefixing) to achieve certain effects without fallbacks or polyfills for other browsers.
  • Browser vendors who rush to implement features developers want before they are standardized.
  • Browser vendors who are slow to implement standards and fix bugs in their browsers.
  • Sites that employ user agent sniffing to serve different content to different browsers.
  • Developers who are over-reliant on a single toolset (which sometimes only reliably supports a single browser) and may miss cross-browser compatibility bugs.
  • Growth in the industry — intense demand has encouraged many new web developers to join the field, which means developers overall are less experienced on average than they were a few years ago.

Statistics suggesting that browser implementations, developer experience, and developer browser choice may affect cross-browser compatibility.

Some of these challenges have been with us since the early days of the web. But since those days, web development has made great progress. Best practices and modern tools can help us build vibrant experiences on every browser.

So, developers, here are a few things to inspire you to make your next web site work for everyone.

More people use that other browser than you think

Many developers believe the browser they use is the only browser that anyone really uses, therefore they should just develop for it. By some measures, 70% of web developers use Chrome on the desktop. But only about 50% of web traffic across all device types is on Chrome, and only about 62% of web traffic on the desktop is on Chrome. Building and testing only on Chrome alone ignores almost half of global users. (It’s worth pointing out here that different browser share trackers use different methodologies and produce different numbers, and the numbers change quickly and often.)

And browser use varies by geography. Chrome, Firefox and IE/Edge are the top browsers in many locales, but the proportion of users on each varies. German users favor Firefox over Chrome. IE is big in Japan. Quite a few Australians choose Safari. More than 1 in 5 Vietnamese users run a fork of Chromium called Cốc Cốc. Building and testing on just one browser ignores these market differences.

Finally, features present in your browser may not be present in other browsers. Browser vendors implement features on different schedules, so a cool new API in your favorite browser might be missing for a lot of users.

These factors combine in unexpected ways: Choosing an API that isn’t supported in all browsers, testing your site only in one browser, and launching in a market where that browser isn’t dominant could mean excluding substantially more than half of your potential audience. Leaving money on the table. Leaving customers out in the cold. That’s worth making the extra effort to avoid.

Compatibility intersects with accessibility

Building cross-browser compatible web sites means designing and coding for unknown client environments, in order to make content available to the widest possible audience. And that audience undoubtedly includes people with disabilities — probably more than you think. If your web site works in every browser but falls apart in a screen reader, you’re missing a powerful opportunity.

People with disabilities represent a significant market share. For example, in the U.S. alone, there are more visually impaired internet users than all Canadian internet users combined. Modern web features address this audience’s needs; you just have to implement them.

Accessibility techniques don’t just benefit disabled users either — for example:

  • Pages that are more accessible to screen readers are also more accessible to search engine algorithms. Simple accessibility techniques such as using alt-text on images, using descriptive text in links, using CSS for style only (never for meaning), and using HTML5’s semantic tags improve the overall SEO of a page.

  • Transcripts of video content aren’t just good for people with auditory impairments — they are also useful for users on mobile devices in low bandwidth areas that can’t download the video, and people in noisy environments that can’t hear the video. And more text content means more opportunity for relevant keywords, so again, more SEO.

Users won’t switch browsers, they’ll switch sites

You might think that users will switch browsers to use your site. But many won’t or can’t.

Users have no patience for things that don’t work, and they’ll just go to a competitor’s site instead. Failing at a critical point could turn a potential user away forever. According to Akamai,

  • 32% of users who encounter a problem on your site are less likely to make online transactions with your company
  • 35% will have a more negative perception of your company
  • 45% are less likely to visit your web site again
  • And more than 1 in 5 users (22%) will leave for good.

What’s more, many users don’t know how to install a new browser, or even know what a browser is (many users don’t know the difference between a browser, a search engine, and a web site).

And even if users know how to install a new browser, and want to, they might not be able to. Many companies mandate which browsers their employees are allowed to use, and many people use public computers in places like libraries.

For example, Microsoft gave a deadline of Jan. 12, 2016 for users to switch to a newer version of the browser, but in March 2016 more than a third of IE users remained on outdated versions that no longer receive security updates. Over the last year (June 2015-May 2016) 2.07% were running IE8, a browser that Microsoft no longer patches; the same goes for more than three-quarters of the 1.59% on IE9 and for virtually all of the 10.95% who ran IE10 (although it should be noted that the usage of these browsers has dropped significantly since March).

Broken web experiences drive users away. If half of your users are on a different browser, and you want to keep them, testing it in that browser is essential.

Statistics showing that browser use varies by locale, and that broken web sites drive away users.

Compatibility === Craft

Creating for the web is a skilled discipline, not just a menial task — we all want to take pride in what we do, hone our craft, and demonstrate our mastery of it. This involves:

  • Staying current with the latest technologies, frameworks, and techniques.
  • Testing carefully and implementing cross browser/platform apps including fallbacks for less capable browsers. Is the experience acceptable?
  • Making sure your web content is accessible to people with disabilities.
  • Making sure the general look and user experience of your creations is pleasant and fits in with your/your client’s brand.

So, as a web developer, launched sites are your resumé. A high quality experience is important to your users, your peers and your present and future employers.

But so often, time and business constraints get in the way of such things. You have a hard deadline to hit. Your boss only cares about how the site works on their iPad and hasn’t heard of accessibility. You don’t have time to fix that IE bug in this sprint. We do what we can most of the time, rather than what we’d ideally like to do.

It can be tempting to let cross-browser testing become a corner to be cut when deadlines loom, hoping your chosen framework’s testing will cover you. But your site isn’t purely framework code, and you’re responsible for all of it. Testing to ensure that your code works well across browsers is a corner that you should strongly resist cutting.

Writing code that stands up over time; delivering information to anyone who requests it; creating rich functionality that works for all: These are the noble goals of a great web developer.

Modern tools can help

Now you know a few great reasons to make your web site more compatible. But how do you do it?

  • If you’ve found a bug on someone else’s site, file it at webcompat.com! If you’re debugging your own site, read on.
  • Try your site in different browsers and move through it as a user might. Watch the developer console in the browser’s developer tools for errors (most modern desktop browsers have incredibly capable developer tools built in to help you debug issues, even on mobile):
  • If you find a bug that is not in your site, maybe it’s a bug in the browser! Open a bug report so your browser’s developers can fix it:
  • Integrate a popular cross-browser-testing tool into your deploy process, to make cross-browser testing automatic:
  • Understand which browsers have implemented web features before using them on your site:
    • Caniuse
    • MDN’s compatibility tables
    • Kangax’s ECMAScript compatibility tables
  • Explore coding tools that can improve cross-browser compatibility:
  • Go deep. Learn about the web’s many features and quirks. The more you know about it the more you will love it:

Delivering on the web’s promise

The promise of the web is that anyone can access content using any browser on any device. Woven into this promise are some of humanity’s greatest aspirations — self-determination, freedom, education and discovery. Designing for cross-browser compatibility opens your work up to the largest possible audience and market, advances your mastery of the craft, and is a noble end in itself.

While the modern device and browser landscape presents many challenges, modern tools offer many solutions. More than 3 billion people are out there looking for your site — is it ready for them?

About Justin Crawford

Justin Crawford is a product engineer at Mozilla, working on developer marketing and growth. He likes thinking about the future, building things and riding bikes.

More articles by Justin Crawford…

About Chris Mills

Chris Mills is a senior tech writer at Mozilla, where he writes docs and demos about open web apps, HTML/CSS/JavaScript, A11y, WebAssembly, and more. He loves tinkering around with web technologies, and gives occasional tech talks at conferences and universities. He used to work for Opera and W3C, and enjoys playing heavy metal drums and drinking good beer. He lives near Manchester, UK, with his good lady and three beautiful children.

More articles by Chris Mills…

About Ali Spivak

@alispivak. Ali is the head of Developer Ecosystem at Mozilla, and has been developing and managing web sites for longer than she cares to admit. She's passionate about keeping the web open and working on things developers love (like MDN).

More articles by Ali Spivak…


37 comments

  1. Ada Rose Edwards

    Another cool tool to enable cross site compatibility is the polyfill service: https://cdn.polyfill.io/v2/docs/

    July 6th, 2016 at 06:48

  2. Lucas Magroski

    “But only about 57% of the general population use Chrome across all device types, and only about 45% of the general population use Chrome on the desktop.”

    Those numbers are swapped. At least, according to the link you posted (http://gs.statcounter.com/)

    July 6th, 2016 at 07:39

  3. Lucas Magroski

    According to the link you shared, those numbers are swapped: “But only about 57% of the general population use Chrome across all device types, and only about 45% of the general population use Chrome on the desktop.”

    July 6th, 2016 at 07:51

    1. Chris Mills

      The stat counter link shows a graph of Top 5 desktop, tablet and console browsers, June 2015 to June 2016. The June 2016 stat for Chrome is about 57%. So I believe it is correct as written. The 45% figure will have probably been gotten from http://gs.statcounter.com/#mobile_browser-ww-monthly-201506-201606.

      July 6th, 2016 at 09:03

    2. Chris Mills

      I think one of my colleagues just changed it before I commented; I think you were right initially, but we have fixed it now. Sorry for the confusion ;-)

      July 6th, 2016 at 09:08

  4. Richard Everett

    The layout of this page looks borked in IE11 – the text takes up a narrow portion on the left of the browser window.

    Not much better in Chrome where the body of the article is not-really-centre-aligned.

    Is this meant to be ironic?

    July 6th, 2016 at 08:10

    1. Chris Mills

      Sadly not ;-) There seems to be a strange setting on the paragraph width; we are investigating this now. Thanks for bringing it up.

      July 6th, 2016 at 09:23

    2. Potch

      Sincerity is the new irony. The narrow text column is intended and not a bug- 65-75 characters is considered to be a good line length for readability. However, we don’t constrain the images to the same dimensions.

      July 6th, 2016 at 10:41

    3. Potch

      As per the IE11 borkage- we’re updating the site to fix that issue as we speak.

      July 6th, 2016 at 11:39

  5. Nicolas Grilly

    “The 18.2% of IE users running IE8 are on a browser that Microsoft no longer patches”: where does this figure come from?

    July 6th, 2016 at 08:32

    1. Ali Spivak

      That figure was from March 2016. At the end of June, the numbers have dropped quite a bit, which is probably why it looked off.

      July 6th, 2016 at 10:08

    2. Nicolas Grilly

      Did you update the article?

      The part I quoted is now replaced by: “The 2.07% of users currently running IE8 are on a browser that Microsoft no longer patches” (which looks more sensible).

      July 7th, 2016 at 05:31

      1. Chris Mills

        Yup, we made some updates.

        July 7th, 2016 at 05:39

        1. Nicolas Grilly

          Ok, thanks. I guess it was a typo ;-)

          July 7th, 2016 at 05:39

  6. Ken

    Great stats and fun report to read. However, under Cross Browser Testing you list Travis which is incorrect. Travis is a CI Server, not a cross browser testing tool / service.

    July 6th, 2016 at 10:40

    1. Chris Mills

      I don’t know how that slipped in there…removed ;-)

      July 6th, 2016 at 10:47

  7. Mark

    Another cross browser test tool that I use: https://testingbot.com
    Create a test and run it on all browser versions to see if your website looks and behaves correctly on old/new versions

    July 6th, 2016 at 11:15

  8. bl4de

    So after almost 20 years of World Wide Web we’re almost exactly in the same place as we were in late 90s :)

    “To see this webpage you need Internet Explorer and 640×480 screen resolution” – or similar, remember that? :D

    July 6th, 2016 at 11:51

    1. Chris Mills

      Exciting pace of change, huh? ;-)

      July 7th, 2016 at 01:19

  9. Vincent

    The second infographic says “Developers are ignoring at least 43% of users if they only build for Chrome”. According to the text, though, that 43% is people who *do* use Chrome (which would also make sense given the colours used), so 57% of users would be ignored.

    July 6th, 2016 at 12:20

  10. Vincent

    I now see that, w.r.t. my earlier comment, the text has been updated compared to what’s in my feed reader. The infographic really should use the same colour for Chrome’s usage share then, though.

    (My previous comment isn’t published yet, that’s why I’m not replying to it…)

    July 6th, 2016 at 12:36

  11. Web Axe

    Nice article. Suggest returning the underline to the text links in text blocks so they’re accessible to all (particularly folks with a deficiency in seeing colors).

    July 6th, 2016 at 18:23

    1. Chris Mills

      They are underlined, now at least.

      July 7th, 2016 at 01:19

  12. Jeremy

    Almost have all the stats ironed out…

    “for virtually all of the 10.95% who ran IE10 last month.”

    The link lists IE11 as 10.93% and IE10 having 1.46%. But that is actually for the last year. You might use this link to jump directly to the numbers for last month: http://gs.statcounter.com/#desktop-browser_version_partially_combined-ww-monthly-201606-201606-bar

    but then the numbers are:
    IE11 8.93%
    IE10 0.74%
    IE9 0.77%
    IE8 1.16%

    July 6th, 2016 at 22:10

  13. Rafael

    Very nice reading. I believe that the industry is pretty diverse though. There’s no consideration for the user target here – do we want to develop for these browsers? Sometimes we (companies, developers, etc) simply do not have the interest and I believe it’s fine. Tools like Google Analytics can also show you from where your users are coming from to see if you targeted it right. There are so many legacy systems made only for Internet Explorer out there, these things will never change.

    For all the rest, websites with long life spam or that should really matter, these tips are good.

    July 6th, 2016 at 22:52

    1. Chris Mills

      It’s always an ideal — do as much as you reasonably can — rather than an absolute. If you do have a very specific target audience in mind, then it is often fine, but we still see too many instances where sites are needlessly made incompatible, and could be opened up to a wider audience with a small amount of extra effort.

      July 7th, 2016 at 01:25

  14. Yves

    Hi,
    Interesting article, and I appreciate the concern for accessibility.
    Regarding accessibility, what do you think about client-side web page generation (Angular, React…)? Is it really possible to have Javascript-laden web pages or a “single-page application”, and still remain accessible to all the people with disabilities?
    Cheers,
    Yves.

    July 7th, 2016 at 00:43

    1. Chris Mills

      In theory you should be able to make complex web app functionality accessible with proper use of WAI-ARIA attributes, progressive enhancement, semantic elements, etc. This obviously gets more tricky, the more complex the app in question is. Another alternative is to provide an accessible version of the site or app that exposes the key content or services.

      For fundamental features like HTML Forms and text, there is not really much excuse for not making them accessible if they are marked up properly and their default behaviour is not broken.

      July 7th, 2016 at 01:30

  15. Niels Matthijs

    Not to be pedantic, but if you use stats it’s essential to use the correct ones. StatCounter doesn’t measure users but usage. If you want users, you should use netmarketshare as your source (the numbers are quite different there).

    July 7th, 2016 at 03:29

    1. Chris Mills

      I think you are being a tad over-pedantic here. users versus usage (of browsers, by users). The numbers are different but the trend shown is basically the same in most cases.

      July 7th, 2016 at 04:50

      1. Niels Matthijs

        Well yes, but why not use the correct numbers then? With Chrome at 48% (which is also better for your case, since more than half the users don’t use Chrome), IE + Edge at 35% and Firefox at 8%.

        At the very least it doesn’t look like you guys are cherrypicking numbers that work best for Firefox ;)

        July 7th, 2016 at 04:56

        1. Chris Mills

          I see your point about that Chrome number being slightly better for our argument, but there’s also the difference between numbers for just desktop, and mobile as well, plus it shows Firefox at a smaller percentage, which from our own stats feels less accurate (and hurts us more to read it ;-) ).

          It just wasn’t that simple to choose a stat, you know? ;-)

          July 7th, 2016 at 05:02

  16. Dietrich Ayala

    CSSLint warns on various browser compatibility issues, so you can know about compat issues while you’re writing code!

    https://github.com/CSSLint/csslint/wiki/Rules#compatibility

    July 7th, 2016 at 09:56

  17. Dietrich Ayala

    Here’s an Applescript to open up Chrome tabs in both Safari and Firefox for compatibility testing:

    https://gist.github.com/autonome/c6d26250125047963f322f837a7aefa2

    July 7th, 2016 at 17:17

  18. Hiroyuki Hatanaka

    Your charts are all in low color contrast and uses same hue in colors.
    They are NOT for the color blind or weak eyesight people.
    Not for “everyone”.

    July 14th, 2016 at 16:44

    1. Chris Mills

      While I admire your care and commitment to accessibility, I think you are being a little over zealous here. The blue background and white informational text contrast passes WCAG AA (I just checked it). The blue text doesn’t, but it is generally being used for headlines/large quotes and not informational text.

      We could improve on that a bit in future articles, and it is good to never lose sight of this. Thanks for the comment.

      July 15th, 2016 at 01:25

  19. Daniel

    Another cross browser testing tool: http://www.browseemall.com

    August 2nd, 2016 at 15:16

Comments are closed for this article.