“I get no respect. The way my luck is running, if I was a politician I would be honest.” ― Rodney Dangerfield
I bet you if the Firefox browser could talk, it would say something just like that. Why are we forgetting Firefox? Why aren't we testing (if you're not) in other browsers besides Chrome?
Maybe you're not forgetting other browsers like Firefox, but are you asking around to see if your engineering friends and colleagues are?
Chrome makes up 65.87% of the market share (as of June 2022), reminiscent of the old browsers wars some of us (myself included) who are long in the tooth saw before with Internet Explorer and Netscape.
In my accessibility work these days I am continuing to see a worrying trend. Development of sites and applications for the browser using one browser. Chrome. I don't see a lot of organizations or teams that are taking this into consideration. There are other browsers on the market.
"What does that have to do with accessibility?"
Two major browsers, two different rendering engines. Those are glaring differences right from the start. Quantum (and Gecko) are what Firefox uses (and used) to power the browser. Chromium, of course, for Chrome.
Some things don't work or act differently in one browser. Screen readers for instance. NVDA works better in Firefox than it would in Chrome. That has an impact on accessibility. A huge impact. JAWS is optimal for Chrome. Nuances that need to be tested.
The biggest thing though that I see is the lack of testing in Firefox. I don't think developers or engineers are asking themselves that question? I can even say this about Safari and Edge as well.
JAWS has partial support in Chrome for the alert role. Firefox fully supports alert. There is full support for the option element in Chrome and only partial support in Firefox. You can see other differences at a11ysupport.io.
It's these little nuances that can make or break something accessibility-wise that developers and engineers need to make sure they cover or it could mean something is inaccessible.
Why do we forget?
Was it because Firefox has slipped to fourth in market share?
Are Chrome's DevTools better? Rhetorical question because I do think they are slightly better but, Firefox's amazing Accessibility panel shines, which is why I use Firefox.
I know when I am head down and working as hard and as fast as I can to get my list of daily items done, I can be laser-focused and not pay attention to anything around me and I can forget to check.
I have a note, on my desk. Since I do not test in Chrome, I always look and see that note that reads:
There are a lot of examples I could list that personally, I have run into. Recent audits I have found keyboard issues with input type="date", visually hidden content, accessible name in an element. Those are just a few. In the landscape of frameworks and CSS libraries we need to be more vigiliant.
The bottom line is make sure things are copacetic between Chrome and other browsers. Accessibility of those components or applications and sites depend on it. Users most importantly depend on it.
You may be a Chrome power user, you may like the DevTools best for Firefox, whatever reason you have, let's try to test things in those browsers that other people use. It may be 3% for Firefox users, it might be the 18% who are Safari users.
You never know who is using the product. We are not the product. We don't make things for the Web when we are employed for ourselves. We make them for the users. The people on the other side of the glass. "It works on my machine." isn't cutting it these days.
Remember Firefox (and the other browsers) please.
Hero Image by Rubaitul Azad on Unsplash
Latest comments (28)
I'm actually impressed with Firefox after version 60. It's become my daily driver again after 10-ish years
Mozilla's management has been systematically destroying Firefox for years, until even the hardcore fans started to switch. Now the only hope is for another org to fork it.
i prefer firefox, but i use chrome for dev because that is what my users have, and i can se exatly what they can see, and on the firefox these things just works(and better)
Responsive Design Mode in FF is pretty cool, it's a pleasure using it. Of course Chrome also has this functionality, but I prefer FF anyway. It just feel right to use Firefox as often as possible, even despite the recent switch from apt to snap by Canonical and Mozilla.
Great article, thanks!
I am a long time Firefox user and because of it I came across scenarios where Chrome falls short
That’s interesting. I use Firefox primarily, and have all major browsers pinned for testing when needed. Most devs I worked with recently also use Firefox as their primary.
I wonder if that’s regional to a degree. While I was in the US chrome was everyone’s default choice that I knew. In France it was Firefox, mostly because it’s better for privacy.
Either way, 100% agree with you on cross browser testing. Should be part of our regular dev process.
Yep... same here... 99% percent of my time i'm on Firefox and where I work most devs are on Firefox
We simply make like they don't exists for two reasons:
Few exceptions on that are styles in which Safari is the new Internet Explorer. The aberrant lack of support and maintenance Apple provide to it's own browser is just the reason for which the major part of Apple devices users use Safari for what it deserves: to download Chrome.
On the other side I'm not buying a Mac just to test in Safari so it's an issue to report (if any) for QA team on a later stage.
Firefox, Opera, Brave, Edge and others have so few user count together (and even less when you analyse the business specific customer traffic) that are not worth mentioning or just a quick check from time to time is enough (as dev), again, QA will spot if anything wrong.
I've just a iPad mini to test webApps I do as freelancer because I'm the QA as well in this situation but nothing else 😂😅
I find Chrome devtools more usable than FF one as well.
The rest of issues related to usability are flaws for not adequately implement web standards. Though is a joke talking about web standards as they doesn't exists as if or if we relied on what's considered canonical (ignoring the rest) we would still doing web apps like 10 years ago.
That's not entirely true. For CSS support, Chrome is just slightly behind Fx in what it supports: w3schools.com/csSref/css3_browsers... . For Javascript APIs, Chrome is lagging behind a little more: developer.mozilla.org/en-US/docs/M... .
So, while it's true that Chrome is used more than Fx, it's not true that it has better support for anything, but in reality it may depend on the features that you know of and are using (although I would suspect a little bias on the features you're using if you're favouring Chrome first).
While this is true to get support for most things, there are some APIs that can't be easily polyfilled, like the speech APIs, or the way that the DOM is parsed into an accessibility tree. Fx does an amazing job at the latter, and it shows through the built-in accessibility dev tools, as well as how well it works with NVDA, which is the leading screen reader on Windows after it overtook JAWs.
As an aside, for testing purposes, while it is extremely beneficial to have access to the actual devices you'd be testing on, there are a lot of platforms out there that allow you to test different browsers across a variety of different computers and mobiles. They're not without flaws, but they get you 99.9% of the way.
Sure if you (they) trim the data 😂
Entered here: developer.mozilla.org/en-US/docs/M...
Saw that there's no reference to the Intl entire API (such segmenter) and hit Ctrl+W.
That is only one aspect of one set of APIs which seem to not be on the list. Do you have a fuller list to support your argument, or is it only the one API?
As you will understand, I am not going to review everything to make a list of items that are not inside that list.
I just checked the first I know its not well supported in FF and I did found that it wasn't in the list, hence the list is incomplete. 🤷♂️
I understand, but I've found many things in the past that Chrome doesn't support that I needed to use, and had to resort to workarounds. For example, things like MathML, various accessibility features where Chrome failed to correctly parse the DOM to build a correct accessibility tree. Chrome even decided (and wisely u-turned) to remove
alert(),confirm(), andprompt()functionality (in some situations), which completely broke whole parts of the Internet.Given that, I'd say it's a very sensible approach to include Fx and Chrome in the browsers you test with.
As the author mentioned, it's not about your personal preference, but about the preference of your users. They might prefer safari because of safari's focus on security, and keeping your data private, while chrome focuses on collecting as much data about you as possible to serve you ads...
As I said, there is enough % of users on Safari to justify extra work in development (that does not mean that it seems a good thing to me, a single open source engine which all companies develop and use would be way better).
BTW the only difference between Chrome and Safari is that Google is transparent and say they link the browser history to your uuid while Apple says Safari doesn't.
Tell me then how is your browser history shared across different Apple devices. Oh wait...
Apple also collects and uses your personal data for targeted advertising through in-App ads. Just like Google, not more, not less. Check this post
Maybe governments are the most dangerous entities that may request data, check this as sample, if it was a valid request you won't notice it, still your data would be shared anyway.
I agree, Safari can be painful when it comes to CSS & JS stuff, unfortunately :/ On the other hand, once your application will work on Safari, it will most probably run on the other browsers, as well :)
You still need to check for vendor (PWA, certain service worker stuff...) 😕
Yes, yes, of course
Polyfill only cover the logic/script of your app. It doesn't cover the styling. Each browser has different interpretation on how to render the stylesheet.
Yup,. that's what I said:
But thanks to clarify, my text was not so clear 😂
That might be so, however all web browsers running on iOS and iPadOS use the WebKit rendering engine. That’s worth repeating: Chrome on iOS and iPadOS uses WebKit to render websites, not Chromium. This ensures that a website rendered on one iPhone in one browser renders reliably the same on another iPhone in all other browsers. The only benefits to downloading an alternative browser like Chrome (on your iPhone or iPad) are syncing your user data (bookmarks, passwords, etc.) and choice of an alternative UI. It’s for this reason that it’s crucial to implement and test for Safari.
These days, Safari has pretty great support for many of the latest browser features. Will it ever be “bleeding edge”? No. Should we be implementing or relying on such features in production websites/applications? Conventional wisdom says probably not.
At the end of the day, as long as you are implementing and testing based on the browser and device usage of your project’s user base, you can’t go too wrong.
Yes, but the support comes at late. The other thing is the support for the not-latest features. As Joel mentioned, there are some functionalities that has unfortunately been left over by the Safari development team, and it seems they will never get fixed.
Agree on everything.
What affects me from the first paragraph is that I need to subcontract iOS webviews just cause Apple don't support PWAs nor let other browsers support webApps in iOS... That greedy bastards.
Either way yes, we're limited by this and we'll be till they want and we need to align with that "ruleset"
From WebDev perspective I can only think 2 reasons:
There is also a problem on how to do cross-testing on various JS engine but I think that's a very specific to lib/framework maintainer.
Well, I'm not much into E2E testing but Playwright is considerably more extense and robust than puppeteer, I don't know the list of features nor used it for anything that's not web scrapping 😂
Yups, I use that too when cypress is a bit too much for small project. Kinda sad that there is no headless e2e test runner that doesn't rely on nodejs. At most my best choice is to use chromedp but I need to write my test in Go 😂
Haha as I write JS mostly didn't check that honestly 😅.
Did Google add support for Go in Puppeteer?
Nope. It just a Go package for driving chrome browser.
github.com/chromedp/chromedp