On the importance of testing with content blockers

category: thoughts

I recommend everyone to browse with content blockers turned on. The goal: protection against tracking. Safari and Firefox have good tracking protection features. With more people using these features, we should test our sites with content blockers turned on.

Content blocking

In the age of surveillance capitalism, some browsers have started getting more aggressive in how they block ad trackers to protect the privacy of their users.

Firefox has had Tracking Protection since version 42. It works with a blacklist of domains. When something is blocked, it will show up in the Dev Tools Console (“The resource at X was blocked, because tracking protection is enabled”).

Safari not only can block trackers for you, it also allows third parties to define blocking behaviour. Third party blockers can match patterns in URLs and detect things like the domain a script is loaded on (same as site vs not same as site, the latter means third party). When a tracker is identified, developers can choose what to do: block it altogether, just block cookies or hide elements from the page. Users can install one or multiple content trackers. There is a “load without content blockers” feature (long press reload on iOS), but note users may be unaware of it. I know I was until very recently.

What can break

Four examples I encountered in the last few months:

Screenshot of Zara checkout with TypeErrors in dev tools console On this page, I could not select a store or press continue, because Facebook’s tracking script did not load

To understand the last example better, see Stephanie Hobson’s Google Analytics, Privacy, and Event Tracking, which shows how Google Analytics recommended tracking code breaks links for people who block the tracker.

We should not need to track to take people’s money. Or to let them find opening times, open a hamburger menu or follow a link. Metrics can be useful, but they are rarely questioned.

A working website: some strategies

I understand companies want behavioral data in order to improve their sites. But if it puts a stop to taking people’s actual money, doesn’t that defeat the purpose of why you have a website as a company? Is figuring out how many people open your hamburger menu more important than having the feature work at all?

Use no scripts

This one is easy in theory. It is hard in the reality of modern web development, because people will laugh at the suggestion. If your site does not rely on JavaScript to build features like to take people’s money, search for opening times, show a navigation on mobile or go to other pages, these features can potentially just work.

Progressive enhancement

If you manage to develop in a way that does not assume JavaScript (or CSS), you’re likely doing progressive enhancement of some sort. It means that when you build new features, you start with the very basic building blocks, like headings and lists. Simple HTML that describes the feature in a way the most basic browsers understand. You then turn it into something fancy, using web technology a modern as you like. For example, use Web Components to make it tabs, as Andy Bell described. If the fancy thing breaks, the basic building block likely still works.

Not only should progressive enhancement help make your site more robust and resilient, if your whole team can think this way, it can help setting priorities sensibly. See also Resilient Web Design, Jeremy Keith’s free book on building resilient web sites and Dear developer, a talk by Charlie Owen.


To build good websites, I think we should prioritise working websites above gathering potentially useful data (if doing that at all). As developers, we should keep in mind trackers could get blocked and, consequently, never rely on their availability.

Comments & mentions (40)

Tom Bonnike likes this
Stefan Judis likes this
Jasha reposted this
Bernard Nijenhuis replied: Also, testing without content/and blockers can prove to be very useful. I'm not sure what percentage of users has content/ad blockers, but most developers do (oh the irony). Some ads can seriously fuck up the user experience.
Paul van Buuren replied: Ah. Nuttig advies. Onze collega's zouden ook meer moeten testen in browsers die standaard alle cookies weigeren. Er gaat opvallend veel stuk als je beleefd weigert.
Roel Van Gils 07 Jan 2019 10:00:48

Very relevant article, thanks! Last week, I found out that www.dnsbelgium.be (the official TLD registry for .be domains) did not work in Safari with popular content blockers such as 1Blocker and in Chrome when the “I don’t care about cookies” add-on was enabled. I pointed this out on Twitter, but the team was not able to replicate the issue :( (Probably because they forgot to clear cookies first). I haven’t heard back from them. I’ll send them a link to your article ;)

Jewwy Qadri reposted this
Chris Heilmann replied: On the importance of testing with content blockers hiddedevries.nl/en/blog/2019-0…
Pierre Burel reposted this
Johan Groenen replied: hiddedevries.nl/en/blog/2019-0…
Eric Eggert replied: Hidde’s blog has all sorts of (not very hidden *scnr*) gems. This is only the latest:
Jewwy Qadri likes this
Roger Johansson replied: “We should not need to track to take people’s money. Or to let them find opening times, open a hamburger menu or follow a link.”

Roger Johansson replied: “We should not need to track to take people’s money. Or to let them find opening times, open a hamburger menu or follow a link.”

Jason Neel likes this
Steffen Jørgensen likes this
Alex Carpenter reposted this
Baldur Bjarnason @baldur@toot.cafe replied: “On the importance of testing with content blockers” hiddedevries.nl/en/blog/2019-0…
Alex Carpenter likes this
Rhian van Esch likes this
Chris Taylor reposted this
Chris Taylor likes this
Teodora Petkova replied: hiddedevries.nl/en/blog/2019-0… h/t @csarven
Manuel Matuzović reposted this
Manuel Matuzović likes this
Johan Ronsse replied: A blogroll johanronsse.be/2019/01/07/blo… thx @hdv
Roel Groeneveld replied: On the importance of testing with content blockers hiddedevries.nl/en/blog/2019-0…
Deborah Edwards-Onoro replied: Do you test your sites with content blockers turned on? hiddedevries.nl/en/blog/2019-0…
Arnaud Delafosse replied: ⚠️ "On the importance of testing with content blockers".
Prateek Rungta replied: “I could not select a store or press continue, because Facebook’s tracking script did not load.”

Exhibit #73 for why you should not assume JavaScript availability, and build using progressive enhancement instead — content blockers: hiddedevries.nl/en/blog/2019-0…
Miranj replied: “Is figuring out how many people open your hamburger menu more important than having the feature work at all?”

On the importance of testing with content blockers: hiddedevries.nl/en/blog/2019-0…
adrian likes this
Chris Heilmann replied: Book review: The age of surveillance capitalism hiddedevries.nl/en/blog/2019-0…
Peter Sylwester likes this
Stephen Cunliffe likes this
Jon 22 May 2019 14:45:00

Geweldige blog! Het is heel leuk om te lezen. Ik wacht ongeduldig op meer.

Ruud Steltenpool ????????????,????????,????????… reposted this
Alan Starc likes this
Ruud Steltenpool ???? ???? ???? , ???? ???? , ???? ???? … likes this
Hidde de Vries (@hdv) is a freelance front-end and accessibility specialist in Rotterdam (NL), conference speaker and workshop teacher. Currently, he works for the W3C in the WAI team (views are his own). Previously he was at Mozilla, the Dutch government replied:

Wow, the year only has 8 days left! Time for a review.

Like last year, I’ve divided this into highlights and things I learned.



In the first half year of 2019, I continued my project at Mozilla’s Open Innovation team, building their People directory, and worked in the City of The Hague on accessibility and the internal design system.

In July I started a new project: at the W3C’s Web Accessibility Initiative (WAI), I am now working as part of the European Commission-funded WAI-Guide project. My work there is focused on improving the accessibility of/in tools that create web content, like CMSes. In short: we want more accessibility both for content editors (a good editing experience) and for end users (good output).

Apart from my work at the W3C, I’ve been doing the occasional WCAG audit and accessibility/CSS workshop in my own capacity too.


Last year I spoke at my first conference. This year I got the opportunity to do new (and some older) talks in various places.

In March, I did a talk called It’s the markup that matters at De Voorhoede. It was part of their Future Proof Components event, and covered building accessible components, accessibility trees and the AOM.

At WordCamp Rotterdam and Inclusive Design Ghent, I shared 6 ways to make your site more accessible, based on my experience looking at common accessibility problems that front-end developers can do something about.

In October, I presented a very short lightning talk at the Web We Want session at View Source Conference, about how some accessibility problems could cease to exist if browsers would automatically fix them. The problems: zoomability, readability, color contrast and focus indication (the first three are each solved in at least one browser, the fourth has not). This talk, shockingly, won both the jury and audience award.

Also in October was a talk called Breaking barriers with your CMS at the Fronteers Jam Session (on behalf of W3C/WAI). This presented some of my recent work at WAI: it explained ATAG and the role of the CMS in accessibility efforts.

At the Design in Government Conference in November, I talked about the case for web accessibility from philosophical ethics, attending on behalf of W3C, and I did an updated version of my graphic design on the web talk in Dutch for Freshheads in Tilburg.

Then in December, I joined dotCSS to talk about the history of CSS: On the origin of cascades put some of that in a Darwin-themed talk. The venue was enormous and intimidating, and there was transport strikes, but the event itself was excellent, with a great atmosphere and very well organised.

I also did a number of in-house talks and workshops, about CSS Layout, ARIA and accessibility guidelines.


I read much more than last year (72 books so far), and have written more about books on this blog (see reading list about equality and reading list about tech and society). Reading more books helped me read less social media, watch less video and generally relax more.

Some notes:

  • Audiobooks are great as you can read them in situations where holding a book doesn’t work (e.g. walking a dog, housework)
  • To read more, finding the right books is half of the work (I mean, not literally… but it is important). I found more people to follow on Goodreads, keep a close eye on the literary supplements in the papers and love posts like 2018: books in review by Karolina Szczur.
  • Dutch libraries have ebooks and audiobooks that can be ‘borrowed’ via apps.


This year marked over 100 posts on this blog, I wrote 24 posts (including this one).

Some posts that people found interesting:

I also contributed to the Mozilla Hacks blog, writing Indicating focus to improve accessibility and How accessibility trees inform assistive tech. Thanks to Havi Hoffman for the opportunity!


This year I traveled to Antwerp, Berlin, Bristol, Essen, Ghent, Nice, Paris, Taipei and Vienna, using trains where possible, but I need to do better at that.

Things I learned

Here’s some random things that I learned about in the past year:

  • Recently I started working on an app with Svelte, the front-end framework that doesn’t ship in its entirety to the user’s runtime, but tries to compile as much as possible to vanilla JavaScript. Small bundles, yay!
  • As I started my project at the W3C, I learned a lot the standards process, the dynamics in Working Groups and the bots that help run teleconferences.
  • A large part of my work centered around authoring tools, or tools that create web content, and how they can help bring more accessibility in the world.
  • I became increasingly aware of the role of surveillance capitalism in the world.
  • I learned to love AirTable as a way to organise and plan the non-coding parts of my work, which are becoming a larger part of the whole

In any case, I’d like to thank the readers of this blog for reading and sharing the posts I’ve published, it means a lot. I wish you all a great 2020!

Leave a comment
Posted a response to this?

This website uses Webmentions. You can manually notify me if you have posted a response, by entering the URL below.