• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

Silktide are proud to announce the launch of our free Silktide Accessibility Checker, to commemorate Global Accessibility Awareness Day (GAAD).

This free Chrome and Edge extension transforms how easily developers, content creators, and website owners can test for web accessibility.

The Silktide Accessibility Checker can perform comprehensive audits against more than 200 web accessibility checks, simplifying the process of making websites compliant with the latest WCAG 2.2 guidelines.

What can it do?

• Automated checks: Tests web pages against WCAG 2.0, 2.1, and 2.2 guidelines
• Designed for everybody: clear, actionable reports that make resolving issues straightforward
• Mobile and tablet simulations: Test across devices including desktop, tablet, and mobile
• Comprehensive help: Detailed guides and videos to help users understand and rectify issues quickly
• Screen reader simulator: Experience a screen reader without having to install one
• Color contrast checker: Test if your color contrast is sufficient
• Innovative simulations: Various disability simulators to enhance empathy and understanding

Why should I use an accessibility checker?

Web accessibility helps make sure your website is usable by as many people as possible, regardless of their ability. In becoming accessible, you open your web content to as many people as possible.

Increasingly this is becoming a fundamental human right. There are many accessibility laws globally that mandate a minimum level of accessibility.

Regular accessibility auditing is key, but it can be quite a challenging topic to learn. That’s why we created this easy-to-understand free tool – to help you understand the fundamentals of web accessibility.

How is this better than other accessibility checkers?

There are plenty of accessibility checkers, but we’ve been consistently frustrated by how difficult they are to use. Most are designed by developers, for developers.

We decided we could do better.

Our checker purposely is built on the best features we’ve found from others, with a focus on ease of use.

We also decided to make one of the most elusive aspects of web accessibility more available to non-experts. Our Accessibility Checker includes a screen reader simulator, which allows users to test for a screen reader experience without the pain of having to pay for, install, and learn one.

How to install

Visit the Chrome store to install the browser extension. It’s compatible with Chrome and Edge browsers.

Overview

About Silktide

Silktide is the web intelligence company helping businesses and organizations make their websites better.

We’re committed to enhancing the accessibility of the web. Our tools are designed to help people create a more inclusive digital space, ensuring that everyone, regardless of ability, can enjoy all that the web has to offer.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

We’re pleased to announce that access to all Silktide AI features is no longer limited to a given number of requests.

All customers now have unlimited number* of credits for the following AI features:

• Ask AI Ask AI for help solving a problem with a specific webpage
• Improve UX Ask AI for help improving the User Experience of a specific webpage

Learn what AI can do for your website

Check our our recent webinar series on AI:

How AI will revolutionize accessibility – Silktide

How AI is transforming web design – Silktide

How AI will revolutionize web governance – Silktide

The small print

*Use of all Silktide AI features is subject to fair use. If we detect any abusive use of AI, we reserve the right to limit or discontinue access to it at our discretion.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

We’re delighted to announce that as of today, all customers can use the Silktide platform in any of the following languages.

• English (US)
• English (UK)
• Spanish
• German
• French
• Canadian French
• Italian
• Norwegian (Bokmål)
• Swedish
• Danish
• Dutch
• Finnish
• Japanese

You can access these languages inside your account, by clicking on your user menu, and clicking Settings. Or you can ask your Silktide contact to update the default language for your whole account.

A radical new approach to translation

It is usually considered best practice not to translate your software too early, as doing so slows down product development. After translation, every feature you release requires more testing, translation, and cost.

This wasn’t acceptable to us. Silktide is still in the early phase of our product vision. So we needed a way to support more languages without development being slowed down.

To do this, we pioneered the use of a new AI-augmented translation framework.

By leveraging the power of modern LLMs (Large Language Models), Silktide has been able to automate the production of high quality translations. We can release new features, and have AI-generated translations immediately available at launch, without introducing any delays.

Crucially though, we still keep humans in the loop. Our staff and our community can review and improve our translations in real time – without even needing to deploy a new release of our software.

How this is revolutionary

Traditional machine translations are poor. Normally, relying on automated translation would result in an unacceptably poor experience.

But with LLMs, machine translation has advanced dramatically. A key part of our new design was to embed our translatable text with context, such as “The following text is for buttons. Buttons should be short, and be expressed consistently.”

With context, we are able to dramatically improve how well both AI and humans can translate without a laborious back-and-forth testing process. Previous AI had no capacity to do this.

We’re also able to use AI to double-check the output of the AI. For example, we can feed screenshots of our application into a vision-based model, and have it assess whether the text makes sense in context.

The future

These languages are just the start of what Silktide will eventually support. With our new technology, we’re able to add more languages more easily than is normally considered possible.

We have a lot more planned for Silktide this year, including many new applications of AI, so stay tuned.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

No, really. You can make a start with web accessibility by using free accessibility tools.

We’ll show you how you can check a page on your site for web accessibility problems for free, and explain some fundamental concepts that you might not know.

What you’ll need to follow along:

• the Silktide accessibility checker, a free Chrome extension
• an example web page to check, we’ll use our testing website fake-university.com

What this article will help you check:

• Over 200 individual WCAG accessibility checks
• Color contrast checker
• Alt text
• Headings
• Screen reader simulator
• Focus order
• Landmarks
• Impaired vision simulator
• Color blindness simulator
• Dyslexia simulator

Prefer this blog in video form? Here’s the video from YouTube.

What is web accessibility?

Good web accessibility makes your website as easy to use as possible for everybody. This includes people with visual impairments, who might rely on assistive technologies like a screen reader to read the page contents.

People with a motor impairment might use a keyboard instead of a mouse to navigate a website.

Other people might prefer to use a mobile device for all their web browsing, so your websites should be responsive and compatible.

Some people might be in a situation that makes it harder to see their device, like bright sunlight.

The solutions to these problems (ensuring keyboard compatibility, mobile responsiveness, and readability through sufficient text contrast) benefit everybody.

Ultimately, web accessibility means web usability. So the more usable your website is, the more people can use it and get the information they need, or make the purchase they need.

By checking your web accessibility, you’ll find and fix these usability barriers that prevent people from completing the tasks they need to on your site. This reduces your support burden and increases your conversion rates. All public sector bodies and, depending on your location and industry, most private sector bodies are subject to web accessibility legislation.

Let’s look at how you can check your web accessibility for free.

Step by step: check web accessibility for free with Silktide’s accessibility checker

Now that we have some background, let’s dig into some practicalities of checking your web page’s accessibility.

1) Install the Silktide accessibility checker

Navigate to the Silktide Accessibility Checker on the Chrome web store and click the “Add to Chrome’ button.

Next, click the jigsaw in the Chrome extensions bar and pin Silktide so you can easily access it.

2) Run the accessibility check

Choose a page you want to test for accessibility problems and open it in your browser. We’ll choose our testing website, fake-university.com.

Click the Silktide Chrome extension icon, and the accessibility checker tool panel will open.

There’s a range of free accessibility tools available that help you check different aspects of your web page. The Silktide free accessibility checker contains over 200 WCAG (Web Content Accessibility Guidelines – video) tests in an easy-to-understand format. You can work through each and we’d recommend starting with the Accessibility checker.

• Accessibility checker
• Color contrast checker
• Alt text
• Screen reader simulator
• Focus order
• Landmarks
• Impaired vision simulator
• Color blindness simulator
• Dyslexia simulator

3) Work through each section in the accessibility checker

The accessibility checker gives you over 200 free accessibility checks. After a brief scan of your web page, you’ll see the panel populate with a list of problems in order of severity.

Before we delve into each issue, take a look at what’s included here. At the top of the panel, you’ll see a dropdown menu with the option to preview the web page on desktop, tablet, or mobile devices. This gives you a quick overview of how your site displays on different devices.

Below this are the filters for the types of check and the WCAG standard.

• Automated: Checks which Silktide carries out with a distinct pass/fail
• Assisted: Checks which Silktide can alert you to check manually, but does not give a definitive pass/fail

For now, we’ll leave everything as it is and choose one of the checks to look at. Each issue type can be expanded with a click, and you’ll see the problem highlighted on the page

In our case, we’ll look at the list of color contrast failures.

An example: Color contrast check

For our test website, all the links in the footer fail color contrast requirements, with a much too light gray color on the light grey background.

So the accessibility checker highlights each of these on the page for you and explains:

• what the problem is
• why it’s a problem
• how to fix it.

The left-hand panel gives you the explanations and the guidance you need. We’ve made a big effort to make everything easy to understand because WCAG is a tough subject.

In this case, the suggestion is to darken the footer link text.

This is important because people with moderate visual impairments, or those looking at their screen in bright sunlight, won’t be able to read the links.

Another example – “Read more” links

Screen reader users may skip through your website listening only to the links. If each link has the same text but points to a different destination, and also has non-descriptive text like ‘Read more’, this leads to a poor user experience.

In an example like the screenshot below, which lists multiple blog posts in a grid each with an identical ‘Read more’ link text, the screen reader will read out “‘Read more – Link’, ‘Read more – Link’, ‘Read more – Link'”.

Listening to that, you would have no idea where each link leads.

The problem is solved by using descriptive link text or context-giving ARIA labels, which are not visible but are read out by screen readers.

These are just two of many examples. Each check in the Silktide Accessibility Checker has a description of the problem and how to solve it, so you’ll be able to learn about these problems as you work through each page.

4) Check color contrast

High-contrast text is easier for people to read. WCAG gives some guidelines as to how contrasting it must be.

You can check any two colors by hex code.

You can type them in or use the color pickers to choose two colors from anywhere on your screen.

5) Review your image alt text

Alternative text (‘alt text’) is used by screen reader users to read out descriptive content of the contents of an image. It’s incredibly useful, and also necessary in some cases.

For example, let’s say you have a graph on the page, but no supporting text content. The image contains useful information (the graph data) that can’t be accessed by someone who can’t see it.

We’ve written a whole blog on when to use alt text, how to use it, and importantly, when not to use it.

The alt text tool in the Silktide Accessibility checker lets you easily see where the images are on the site, which ones have alt text and what it is, and also which ones are missing alt text entirely. It also alerts you to missing alt tags, which are required in HTML for images, even if the image is decorative.

Silktide helps you decide whether the alt text is decorative, useful, or irrelevant, with the support help content shown on the left menu. Because everything is laid out visually, it’s easy to see what’s happening on your page without looking at the code or in your CMS for each image.

6) Review the focus order for keyboard navigation

People can navigate through a website using their keyboard. A combination of TAB and SHIFT + TAB lets you move forward and back through the page.

Your website must be built so that when navigating with a keyboard, the order is logical.

The Focus Order check gives you a visual representation of how your website’s navigation order is laid out, without you having to manually tab through the whole page. You need it to be consistent and logical. Also, you must ensure nothing is missed out.

Our test website has some pretty egregious focus order errors, one of which is highlighted below. The image shows what looks like three images. However, there are actually 6 images, which you can tab through with a keyboard. The order of tabbing does not follow what’s on the page visually.

This is a direct copy of a real website we found in the wild. Don’t try this at home!

7) Review landmarks

Landmarks on a web page are like signs in a building that help everyone find their way around. Imagine if you walked into a library and there were no signs for the different sections. It would be tough to find the books you want, right? Well, landmarks do the same job but for websites. They help organize the website so that it’s easier for everyone to find what they’re looking for, especially for people who use special tools to read the screen because they can’t see it.

Just like how signs in a building are made for everyone to understand, landmarks on a web page need to be set up so computers can understand them too. This helps people who use keyboards to navigate through a website easily, jump over parts they’re not interested in, and find the sections they want.

Silktide highlights the landmarks on a page so you can quickly understand where they are.

7) Use the screen reader simulator

The screen reader simulator is designed to give you a basic understanding of how a screen reader might work. You already have a ‘real’ screen reader built into your phone.

Ours is not designed as a replacement, but simply a tool for beginners to understand how they work (and how they might work on your web page).

Start by opening the screen reader panel and navigating through your page using the left and right arrow keys.

You’ll hear each element being read out. It probably won’t be long before you hear something that doesn’t make sense, or even not hear something you were expecting to.

Now, consider the impact of missing buttons, poorly described alternative text, or missing context, and you’ll understand how important it is to make your website compatible with assistive technologies.

Open the ‘How to use a screen reader’ panel. You’ll see a range of additional keyboard shortcuts. These let you navigate each heading, element, landmark, link, and more.

We encourage you to try the screen reader on your site, especially if you’ve never used one before.

8) Use the impaired vision simulator

We’ve included several simulations of visual impairments, ranging from myopia to loss of peripheral vision.

To access these, click the ‘Impaired Vision’ tab and on any simulation. You can adjust the amount using the sliders.

This is important as it helps you understand how people with moderate to severe visual impairments might view your website.

9) Use the color blindness simulator to assess contrast issues

Color blindness affects 8% of all men and about 0.5% of women. It is a common condition that affects the way that people see colors. Globally, over 350 million people are affected by color blindness. We recommend that you test your website while simulating monochromatic vision to make sure it’s accessible to everyone.

To get started, open the Color Blindness Simulator panel.

From the list, choose the simulation you want to test. For example, the loss of green is the most common, but you might want to also check ‘color greatly reduced’ for a more extreme loss of all colors.

Remember, choosing to distinguish elements by color alone is a WCAG failure.

10) Use the dyslexia simulator to assess readability

Dyslexia is the most common learning disorder in the world, affecting 10% of the global population. It affects the way that people read and write.

The letters on a page may appear jumbled, and this causes a greater cognitive burden. Making your content more readable can help, so consider simplifying your text, writing shorter sentences, and using sans-serif fonts.

To use this check, open the Dyslexia Simulator tab. You can adjust the severity (the speed at which the letters on the page jumble) by using the slider.

Congratulations! You’ve got a more accessible web page for free.

If you’ve worked through every step of this guide and used the accompanying help content in the Silktide accessibility checker, you should be in a good position to make changes to your web page.

Of course, the accessibility checker is great for helping you manage a single page at a time, but Silktide also has a full suite of accessibility tools in a single platform, that monitors your entire site for ADA, WCAG, and accessibility compliance problems.

Check out more details about the full Silktide platform here.

If you want more free accessibility resources, we have a range of free accessibility books, a collection of educational videos on our YouTube channel, and an accessibility newsletter.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

The new Silktide Index launches in January 2023. It includes enhanced accessibility testing and WCAG 2.2 support.

Over the past couple of years, Silktide’s website testing and scoring methodology has evolved. We now test for more issues and in some cases, test in different ways. We’ve upgraded some score weightings to reflect the importance of various accessibility issues. WCAG 2.2 accessibility testing is now included.

We’ve updated the Silktide Index to reflect these changes and advances in technologies.

What does this mean for you?

In short:

• Silktide Index now includes WCAG 2.2 checks
• Accessibility tests now match the Silktide platform
• Scores will change, some dramatically so

Why are the scores changing?

The approach for calculating scores is fundamentally different between the older version of the Silktide Index and the new one. You should not expect scores between the versions to match.

Think of it like how schools change their grading system each year. You can compare the grades of one child from 2010 with another in 2020, but they won’t (and can’t) be the same, as the criteria change.

There’s not a simple explanation for what has changed – there are new criteria, new concepts, and new approaches. For a technical explanation of the Index algorithm changes please visit this support article.

If you are a paid Silktide customer, you can expect the scores in the Index to differ from those in your account. Here’s an article that explains why Index scores differ from Silktide customer accounts.

Benefits

Broadly speaking, these changes:

• Improve scoring accuracy
• Bring some accessibility areas up-to-date
• Allow for more accurate identification of issues
• Add WCAG 2.2 success criteria
• Bring scoring between the Silktide Index and our customer’s reports more closely together

Things to consider

The following points have not changed since the previous Silktide Index but they are worth highlighting here:

• In most cases, we are testing a sample of up to 125 pages
• Those pages are unlikely to be the same each month
• Any ‘decisions’ made in your own report (if you are a customer) are not applied to the Index

What other changes are being made?

In order to expand the Index, we’re streamlining some categories during 2023. We’ll combine multiple similar categories together. A specific example is the combination of all UK NHS websites into a single category.

Later in 2023, we’ll expand Silktide Index to include non-accessibility checks.

What to do next?

In January, Silktide Index will be updated and websites in all categories are likely to see changes in scores and position. This is not something to be alarmed at, but we appreciate that this kind of thing can cause some concern.

Consider this. If your score does change dramatically, check your Silktide Index report to see if new accessibility issues are highlighted. It’s likely with the new and amended testing methodology that there are accessibility problems being found that could not be found before.

Also, the score weighting has changed. Some issues may have become more important, or less important, than in previous reports.

The biggest single change is the inclusion of WCAG 2.2 testing. It’s likely that accessibility issues will be found against the new Success Criteria, which will affect scores.

If you have any specific concerns, then do reach out to us at support@silktide.com and we’ll do our best to address them.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

We decided to get rid of our cookie consent banner and third-party tracking cookies from our website. It was easier than we thought.

Over the last decade, online privacy has been eroded. Advertising companies track your every move online through cookies – pieces of code that let websites and third parties see your browsing activity.

The privacy laws changed in the EU a long while back, and we wrote a comprehensive guide about it. It’s still our most viewed blog post, mainly from people asking Google why cookie popups are even a thing given how terrible they made the Internet.

The reason for cookie consent banners is the vast majority of websites install third-party tracking cookies for marketing purposes. EU law specifically states “You can’t set tracking cookies unless the user explicitly consents to it”. These tracking cookies send data to Big Tech and track you online.

This is fine for most people, they just click “I accept” without considering the consequences. But given the state of what Facebook, as an example, is up to at the moment in terms of circumventing the restrictions placed on it by Apple and the EU, perhaps they’d not be so keen to do so. More on that later.

The most common trackers are:

• Google Analytics (so organizations can understand who’s visiting their site, where they came from, and what they did)
• Twitter (so companies can show targeted ads on Twitter to recent website visitors
• Facebook (so Mark Zuckerberg can take over the entire Internet, see everything you’re doing, and give businesses a terrible and crappy ads interface. Oh, AND track visitors and advertise to them, not just on your website but across ALL websites)

So, what’s wrong with that, I hear you ask. Businesses need to get data on their customers and advertise to them. What’s the big deal? Plus, aren’t you in charge of marketing?

I hear you. But look, Silktide is all about helping people make the web better. We’ve been talking about the crappiness of cookie consent popup banners for about ten years now (we even built one and gave it away for free in an exercise in extreme irony).

But cookie consent banners are merely a band-aid over the real problem – the invasion of user privacy online.

If big tech companies weren’t tracking your every move, we wouldn’t need them.

How did we remove our cookie consent banner?

So, the first thing we needed to do was look at which cookies were being set on silktide.com. Silktide’s web governance platform actually does this already, so that was quite straightforward. Here’s the list:

• Google Tag Manager
• Google Analytics
• Twitter pixel
• Facebook pixel
• Intercom (live chat)

Obviously, setting cookies before consent is a massive no, so we use Google Tag Manager to load everything in, but only once the user explicitly accepts cookies in our cookie consent banner (GTM itself is also only loaded once the user accepts cookies).

That’s the correct way to do it, but you’d be surprised by the number of websites that set cookies automatically before asking permission (and you can read about that in an upcoming post).

The marketers in the room are probably thinking “Wait, what about my ads and analytics”.

We don’t retarget on Google, Twitter, or Facebook. In fact, we barely do any paid advertising, save for a few select keywords in Google Ads, and some recruitment ads on Facebook and LinkedIn. But those don’t require any tracking pixels to be set.

So really, for us, there’s no need to have Facebook and Twitter pixels on our site at all. That’s why I took them off a few months ago.

That just leaves Google Analytics and Google Tag Manager.

We use Tag Manager to handle various functionality, like sending conversion events into Google Analytics and some basic funnels for people clicking on our “Request Demo” button to see if they convert and where they came from.

So turning that off presented some problems for me because it would basically break conversion tracking.

That said, given that we’ve removed Google Analytics anyway, it’s a moot point.

Removing Google Analytics

We no longer use Google Analytics on our website. This is, of course, madness from a marketing perspective, because how is a global SaaS company expected to track user activity and report on marketing metrics? Why is the head of marketing suggesting this is even a Good Thing?

Fret not. We simply built our own cookie-free analytics and heatmapping solution. We got a bit tired of the way Google Analytics works, so built something which still allows user behavior tracking without invading privacy.

It doesn’t need a cookie consent banner, because there are no cookies. Nor is any personal data sent outside the EU, and nor is any personally identifiable user data collected or stored.

Removing Facebook and Twitter

I mentioned earlier that we’d removed Facebook’s pixel. Even if we retargeted users on Facebook, its effectiveness would have dropped significantly since Apple blocked Facebook’s ability to track iOS users.

Also, Google Chrome is blocking third-party cookies by default in 2023, which means Facebook and Twitter advertising will become even less effective in the future. Google, of course, owns Chrome and so that probably helps it track logged-in users even without cookies.

Given that most advertising data is now in aggregate the future seems clear – closed ecosystems with little transparency. Examples include Facebook’s Conversions API – the most insidious counter to EU law you can imagine.

Unfortunately, even without cookies, it’s still going to be possible for Facebook to track you. In fact, with the Conversion API, they’ll get even more personally identifiable data than before. We wrote a blog about that which you can read here.

What about Intercom?

We use Live Chat on our websites and in our app so our customers can talk to us. There are no Live Chat apps that don’t require data transfer, so the only choice here is to remove Intercom from our main silktide.com website.

We are, however, still using it on our support websites and so we kept a cookie consent banner on there to give people the choice. Intercom won’t load at all until you accept cookies.

It’s a compromise. You can still email us if you’d prefer not to use Intercom.

Putting the cookie consent choice back into users’ hands

Users need a choice on privacy at a time that makes sense to them. They should also not be bombarded with cookie consent banners immediately upon visiting every new website.

It’s possible to have comprehensive analytics that also respects user privacy. You can still monitor conversions, you can still see traffic sources, and you can still report on advertising using standard URL tracking templates.

The difference is that no personally-identifiable user data is collected so you don’t need a cookie consent popup to use it. It’s also fully compliant with privacy laws.

The effectiveness of retargeting on Facebook is massively reduced now anyway, especially since Apple blocked third-party cookies on iOS. When Chrome blocks cookies next year, the problem will get even worse.

To find out more about cookie-free, privacy-focused analytics, click here.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

From a certain point of view, Facebook’s solution to having all their advertising cookies blocked is quite elegant. Some would say it’s pure evil. More on the specifics later, but first, some background.

Remember when Apple and Facebook had a bit of a tiff after Apple decided to block third-party tracking cookies in Safari and in iOS 14+?

Well, next year Google will be doing the same, by default, in Chrome. Chrome does of course already have an option to block third-party cookies, but I bet you haven’t switched it on.

By cutting down Facebook’s access to cookie data across the web, their advertising becomes less effective. No longer can they rely on automatic shared data from websites sent via cookies. Instead, they now ‘guesstimate’ retargeting audiences, using a range of anonymized data that groups people with similar interests. They then allow their customers to show ads to these audiences.

The downside, for Facebook, is that they no longer have access to data from specific users either on iOS devices or on browsers where third-party cookies are blocked. This means the retargeting becomes less effective (unless the iOS user has specifically opted into getting personalized ads – which is now off by default since iOS 14).

Facebook wasn’t very happy when Apple did this, even taking out full-page adverts in national newspapers and writing a blog post asking small business owners to speak up against Apple.

“Apple controls an entire ecosystem from device to app store and apps, and uses this power to harm developers and consumers, as well as large platforms like Facebook.”

I mean, there is some level of irony here given that Facebook’s tracking pixel is on most of the websites you visit.

I don’t want to be tracked, so blocking Facebook’s advertising is a good thing, right?

In principle, yes. It won’t be possible to individually target you if you’re using iOS or have third-party cookies blocked elsewhere.

You’ll still get targeted ads, but these might be less effective. Business owners won’t get as much data in their Facebook ads account, as it will use Aggregated Event Measurement (in the case of app install campaigns) to essentially guess what’s happening.

The privacy-conscious among you might welcome this turn of events because now the problem is solved, right? Well, actually, no it’s not.

Things just got a lot worse.

Facebook counters with the Conversions API

When Facebook lost a lot of tracking data through cookies, it came up with a way to still get your customer data to build audiences from. If you’ve spent any time in the Facebook Ads platform recently, you might have come across the Conversions API. 

If you haven’t heard of it, brace yourself.

In the EU, the GDPR law prevents personal data from being transferred without consent, to either the website owner or third parties connected to the website or any technology a business uses.

This is why cookie popup banners exist. We have an extensive post telling you all about how the ‘cookie law’ works.

In a nutshell, if you set a cookie on your website without permission, in the EU, you broke the law. 

You also need to list all the places you send personally identifiable information (PID) in your cookie and privacy policies.

In practical terms, the GDPR/cookie law is actually very enforceable right now, because you can easily scan a website and find out what cookies it uses and, just as importantly, when they were set.

Now, the Conversions API bypasses the need for third-party cookies entirely and collects far more PID than cookies ever could. And Facebook encourages you to use it.

How does Facebook’s Conversions API collect more PID than cookies?

When you fill in a form on a website or buy something through a checkout, you’re giving your data over to the website owner. That’s fair because without it the website couldn’t process your transaction or inquiry, submit your comment, or whatever.

Third parties don’t get access to this personal information (I’m talking about names, email addresses, form values, etc.). It’s not transferred in cookies.

What Facebook is doing is encouraging business owners to give them this data at the point of transaction, so they can use it to match to a Facebook user.

Their dashboard lists what they consider to be “best practices”, with suggestions as to what data you should collect:

• Phone number
• Email address
• IP address

Yes, you heard that correctly. They’re advocating that the “best practice” when using the Conversion API is to transfer your customer’s email address, IP address, and mobile phone number, at a minimum.

Many more options are available in the API, including gender, country, date of birth, and postcode/ZIP.

They say “Customer information is used to match your events to Facebook account ID so you can use them to attribute your ad performance and show ads to people who are most likely to convert.”

Here’s a link to Facebook’s help article listing the customer information parameters that Facebook accepts.

The best thing about this from Facebook’s point of view, of course, is that the business owner is entirely responsible for where and to whom this data is sent.

The Conversions API page, and elsewhere in the Facebook dashboard, states (emphasis mine):

“Note: Ensure that you have obtained the proper lawful permissions and any necessary consent before you share any information with a third party. We provide general information and links to helpful industry resources in our Consent guide, but ultimately you’ll need to work with your own legal counsel to develop your data sharing compliance plan.”

Thereby absolving themselves from any legal liability for receiving the data you give them. That’s right, the business owner is the one getting sued if they don’t include all this information, along with purposes for its use, in their privacy policy.

The worst part about this from a GDPR enforcement perspective is that all this information transfer is “dark”. Cookies can be detected easily, but this transfer of PID is done on the company server.

Only with access to that server code can anyone see what’s actually going on. The data itself is invisible.

So, even though this behavior is subject to GDPR and other privacy laws around the planet, nobody can know unless the web owner tells you. This means the law will be much harder to enforce.

Secondly, and this is even more concerning to privacy advocates, is that there’s no way to block it. No Adblock, no cookie blocking, nothing.

As a consumer, you should assume that Facebook is getting your data whether you’re on iOS or whether you blocked cookies in your favorite browser, as soon as you buy something from an online store that also has a Facebook ad account.

In fact, you’re MORE dependent now on the company being nice and NOT sending all your data.

It gets worse. Businesses can connect their CRM to Facebook and it can receive all the data in all of your form submissions, without even implementing any code.

Oh, and that’s enabled by default.

A clever design

The clever bit is that the design of this ‘solution’ to cookie blocking will ever so subtly influence the business owner to enable all the options.

Which website owners, especially in eCommerce, wouldn’t want to send all this information across especially given that without proper tracking Facebook ads have reduced ROAS by up to 30%.

Remember the wording in the Facebook ad account from earlier?

“Best practices – Selecting the right parameters can help improve your event match quality score and event deduplication, which can lead to better ad performance,” and “make sure you’ve configured the best parameter setup.”

Everything is written to encourage you to hand over as much information as possible.

So, what do we think about all this?

Making the web a better place is in our DNA. But what Facebook is doing here is making it much, much worse, especially in terms of privacy.

You have to hand it to them for coming up with a solution that:

• Enables them to solve the problem of blocked cookies for advertising effectiveness
• Allows them to collect even more data than before
• Removes all liability under GDPR and places it on the website owner

Morally, though, we’d have to disagree with this approach. Internet privacy is a fundamental right, and changes like this threaten it.

The truth is, nobody reads privacy policies, and probably the average consumer doesn’t even care. They’re sharing all their data with Facebook directly anyway, so what’s the big problem?

The problem is that, for the consumer, there is no choice. No way to block or opt out of this behavior, and no way to know it’s happening (without reading through the privacy policy of every website and assuming that businesses disclose all this information transfer as they should do).

We’re taking a stand.

A couple of months ago I removed Facebook and Twitter’s tracking pixels from the Silktide website, along with others.

Our long-term goal is to remove all third-party tracking from Silktide.com in the EU, including Google Analytics.

The result of this is that finally, we’ll be able to get rid of our cookie banner – the bane of the existence of everyone who’s ever visited a website.

Given that I’m a marketing professional, you’re probably asking yourself “Why is the head of marketing at a global tech company removing their web analytics,” and the answer is simple.

We’ve built our own cookie-free analytics solution that’s privacy-focused and works effectively without tracking or storing individual user data.

A problem with most analytics providers, like Google, is that for them to work a cookie must be set. I mentioned before that under GDPR, a business is not allowed to set any cookies until the visitor explicitly clicks “I Accept” in the cookie banner.

This means that anyone who doesn’t accept cookies simply won’t be tracked in your analytics, because Google cannot know about them unless that cookie is accepted.

Silktide Analytics is entirely GDPR compliant and suits organizations in any regulated industry that must adhere to local cookie and privacy laws. Because of that, it can give you analytics data for every visitor, as there’s no need to opt in to cookies (there are none).

Who knows, it might even be the beginning of the end of the cookie banner.

Footnote: Hey fellow Star Wars fans! Yes, we know, this headline isn’t quite canon. But would you rather have Facebook portrayed by Obi-Wan?

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

The European Accessibility Act (EAA) is coming in 2025. Will we finally see improvements in private sector web accessibility?

For some years, the EU public sector has enjoyed the benefits of the EU Web Accessibility Directive – legislation that mandates publicly-funded websites in the EU to be accessible to WCAG 2.1 standards. It was implemented back in September 2020.

What’s been lacking is similar legislation aimed at EU privately-owned businesses. Until now, the private sector has avoided legislation with any teeth in terms of web accessibility. And unfortunately, it shows. We’ve already talked extensively about the disparity between web accessibility in the public and private sectors.

In short, the private sector has, on the whole, far less accessible websites than the public sector. In some sectors, shockingly so.

Two examples of the worst-performing sectors overall in the Silktide Index (our global league table for web accessibility) are grocery stores and fashion retail. This hasn’t exactly been ideal for people stuck at home for extended periods of time during a pandemic.

What is the EAA?

In summary, the European Accessibility Act aims to “harmonize accessibility requirements for certain products and services”. It aims to benefit businesses, the elderly, and people with disabilities. It also aims to clarify existing accessibility obligations in EU law.

From 28 June 2025, the following products and services will be covered by the Directive:

Products

• computers and operating systems
• payment terminals, ATMs, self-service ticket machines, and information terminals
• smartphones and other equipment for accessing telecommunications services
• TV equipment including digital television services
• e-readers

Services

• telephony services
• services to access audiovisual media services
• certain elements of air, bus, rail, and water transport services, such as websites, mobile services, electronic tickets, and information;
• consumer banking
• e-books
• e-commerce
• answering emergency calls to the “112” European emergency number

In terms of the web, the most relevant items here are e-commerce (although this is rather a broad term – more on that later) and specific references to ticketing systems and informational websites.

Importantly, the legislation will not apply to websites and other forms of archive material not updated or edited after 28 June 2025. Nor will it apply to pre-recorded videos published before that date.

The specific accessibility requirements for services include:

• providing information about the service, its accessibility features, and facilities
• making websites and mobile devices easily accessible
• applying practice and policies to address the needs of people with disabilities

What does this mean?

The specific wording of the legislation is available here but it’s a bit involved. I’ll try and summarize the relevant points as they refer to websites.

Audiovisual services

These include websites, web apps, smart TV apps, mobile apps, and related media players and connected TV services.

The Act specifically states that these examples must allow users with disabilities to access them using assistive technologies.

Travel

Real-time travel information must be accessible for rail, air, bus, and water transportation services. This includes information through websites, mobile services and interactive screens, and information terminals.

Important information including pre-journey information, timetables, cancellation and delay notifications, and the available products and services should all be accessible.

The Directive also includes the websites and mobile apps of operators in these sectors. The Index already includes rail operator websites. We’ll expand it in the future to cover other transportation sectors.

E-commerce websites of travel operators are already covered under the EU Web Accessibility Directive – specifically in the sale of tickets for such services online.

Finance

Online banking websites and apps need to be accessible under the EEA. However, there aren’t any specifics on exactly how yet. The wording is (emphasis mine) ‘this Directive should establish common accessibility requirements for certain banking and financial services provided to consumers’.

So while they should establish the requirements, it doesn’t look like they have yet.

Ecommerce

Ok, here’s the big one. When I was researching this post and read “e-commerce” my initial thoughts were, “I hope they don’t just limit this to the travel sector” – mainly because that wouldn’t go far enough.

But it turns out that “e-commerce” does indeed cover all online transactions in the EU. This is, frankly, huge news. Here’s the wording (emphasis mine):

“The e-commerce services accessibility obligations of this Directive should apply to the online sale of any product or service and should therefore also apply to the sale of a product or service covered in its own right under this Directive.”

So, my understanding of this (and I Am Not A Lawyer) is that all e-commerce transactions in the EU will be covered, along with those products and services covered in this Directive.

Now, there are some exclusions. SME’s and other small enterprises should be exempted based on ‘disproportional burden’ – that is, the cost to small businesses of implementing everything in the Directive should not be too high compared to their profitability.

In fact, SMEs and Microenterprises are protected under the Directive, which has adopted a “think small first” principle. You can read more about that in paragraph 64.

What are the accessibility requirements?

Annex I of the Directive contains a very long list of requirements for the products and services covered.

In summary, the products and services need to be designed with the four accessibility principles in mind (perceivable, operable, understandable, robust).

Information should be made available via more than one sensory channel. A good example of this would be something like adding audio descriptions to videos or adding alternative text to images.

Some of the wording is a little vague. For example, in reference to banking services and e-commerce respectively:

• “providing identification methods, electronic signatures, security, and payment services which are perceivable, operable, understandable and robust”
• “ensuring the accessibility of the functionality for identification, security, and payment when delivered as part of a service instead of a product by making it perceivable, operable, understandable and robust”

That said, examples of solutions to common problems are given in Annex II, which is useful. For example:

• “Making the identification dialogues on a screen readable by screen readers so that blind persons can use them.”
• “Making the payment service user interface available by voice so that blind persons can make online purchases independently.”

What about the Web Content Accessibility Guidelines (WCAG)?

WCAG isn’t mentioned anywhere in the Directive. If you don’t know what WCAG is, here’s a 30-second video that explains it.

Why’s that important? Well, WCAG (as you’ll now know if you watched the video) is a set of standards that aims to actually list out all the specific things you should do to make your website more accessible.

It’s a pretty good starting point for most websites, and in fact, the EU Web Accessibility Directive, aimed at the public sector, states that WCAG 2.1 Level AA is where you should aim.

Now, the EAA doesn’t mention this specifically for any of the products or services it covers, but it’s probably a wise idea to aim for the same standards while they decide.

If you want to, you can read through all the WCAG 2.1 guidelines here.

The first thing you’ll notice if you click that link is that WCAG is hard. Really hard. It’s not written in a particularly user-friendly way, and even the web developers who it’s aimed at have difficulty understanding its nuance.

What’s the solution to an inaccessible website?

There are two areas of responsibility when it comes to website accessibility.

• content – usually added by individual contributors across multiple teams, like the marketing and communications team
• the theme and underlying code – usually built and maintained by your developers

I wrote an article about who is responsible for web accessibility (spoiler alert – it’s everybody).

What are the next steps for EU business owners?

So, you have a couple of years before you have to do anything, right? Well, technically, yes. But the ROI of good web accessibility is real, and the sooner you start making your website better, the more income you’ll make and the better you’ll help people access your website.

Also, if you currently know nothing about accessibility (and this is way more common than you might think, so you’re not alone), you’ll need time to consider your options.

First, write an accessibility statement. This should outline your commitment to accessibility and list the areas that you need to improve, and also the steps you’re taking to improve.

Second, check your site for accessibility problems. Obviously, we can help you with that here at Silktide.

Third, consider downloading our free book on accessibility because it gives you a good introduction to what accessibility is and who it affects. It also includes real-world data outlining the top issues we find with our web accessibility testing platform.

It’s aimed at beginners, and you can download the free accessibility book here.

Finally, don’t be overwhelmed. The public sector got through this a couple of years ago, and in fact, they now excel in web accessibility. UK Local and Central Government, for example, rank at the top of all global websites for accessibility. The improvements made during 2020 running up to the EU Web Accessibility Directive deadline were phenomenal, and you can do it too.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

I decided to learn JavaScript with the goal of building an accessibility overlay. I wanted to prove that a) it would be so easy even I could do it, and that b) it would be terrible. I achieved both.

One of the joys of working at Silktide is Silktime, where twice a year each member of our team is encouraged to take a week out of their normal duties to learn something new. Here’s what I learned (in the very loosest sense of the term).

What’s an accessibility overlay, and why build one?

An overlay is added to a website to give users control over things like font sizes, colors, and other functionality. They override the website’s default code, but they don’t help anybody improve accessibility.

This is because they break the standard functionality included in screen readers like JAWS, they don’t affect the underlying web code at all (and so do not solve any accessibility problems) and they won’t protect against lawsuits.

In fact, overlays don’t work at all.

I chose to build one because generally when learning to program, it’s good to set yourself the goal of building a specific project. It forces you to think about the requirements and the features you need to fulfill them.

I also wanted to show what a total scam they are, because if a marketer with barely any experience of coding can make one in a couple of days, that tells you everything you need to know about whether you should buy one or not.

To be very clear, Silktide does not provide an overlay, nor will we. You cannot automatically fix accessibility with AI and two lines of code – computers just aren’t that smart yet.

You can consider this blog post for informational purposes only.

Getting started

A while back I learned HTML and CSS and so I know my way around a web page, but I’d never really learned JavaScript.

The first thing I needed to do was plan out the functionality of my overlay. Here’s a list of the things I wanted it to do:

• Ability to turn the overlay on/off
• Readable font toggle
• Highlight headings toggle
• Highlight links toggle
• Adjust font size
• Adjust line-height
• Adjust letter spacing
• Align text center/left/right
• Dark/Light/Default contrast modes
• Toggle monochrome mode
• Highlight text under the mouse pointer
• Simulate blurred vision

For a complete beginner at JS, perhaps I was being a little ambitious with learning JS and getting all this done in 4 days. However, I’m pleased to say I managed it.

What is JavaScript?

JavaScript (JS) is the programming language web developers use to make a page dynamic. It works with HTML (the code that creates a web page) and CSS (the code that changes the page’s style) to make things move, add functionality, and submit information.

It gives dynamic functionality to otherwise static elements on a page, and basically powers most of the web.

Without JS, the web as we know it wouldn’t work.

You can use JS to find and manipulate all the things on a web page. You can take an element, or collection of elements, and perform an action. For example, you might find all the headings, extract their font size, and then make them bigger or smaller.

To get this to work, you can connect these functions to a button. This is what makes JS dynamic.

Building a test page

There were a few steps to take before actually getting started with the programming.

Step 1 – Create index.html

I needed a page with some test content. I took a copy of a Silktide blog post and created a local version. I wanted to include the following elements:

• headings (h1, h2, h3, etc.)
• paragraphs (p)
• lists (ol, ul, li)
• images (img)
• links (a)
• code (code)

Step 2 – Add basic styling

It didn’t need to be pretty, and as you can see in the image below, it wasn’t.

I started by importing some basic bootstrap and normalizing CSS, then made some basic styling on the font styles, colors, and sizes.

I also created styling CSS for the overlay widget which I built next.

Building the overlay

I created overlay.js, a JavaScript file that handled the creation of the overlay, all the elements within it, and its functionality. There are some examples of functions in the code blocks below. Don’t worry if it looks complicated – you don’t really need to understand what’s going on here.

This particular snippet makes the whole page grayscale by adding a CSS class monochrome to the page body. The monochrome class adds a grayscale filter across the whole page, which is a built-in CSS class for most browsers.

All of this is linked to a toggle button inside the overlay widget.

// turns a whole page grayscale filter on and off by adding or removing a CSS class to the body of the page

function monochromeMode() {
  if (document.body.className == "monochrome") {
    document.body.classList.remove("monochrome");
  } else {
    document.body.className = "monochrome";
  }
}

.monochrome {
  filter: grayscale(100%);
  -webkit-filter: grayscale(100%); /* Chrome 19+, Safari 6+, Safari 6+ iOS */
}

Adding the overlay to the web page

To get it running, I had to add the overlay.js script to the web page, so I did that by using the script tag. All this does is reference JavaScript files located elsewhere (that can be either on your computer, on your web server, or someone else’s web server.

    <script src="scripts/overlay.js" defer></script>

Finally, I imported all the different styles. These included CSS for:-

• the page itself
• the overlay and the override styles that the overlay uses to change the page

    <link rel="stylesheet" type="text/css" href="css/style.css"/>
    <link rel="stylesheet" type="text/css" href="css/overlay.css"/>

Getting it working!

To illustrate how terrible this all is, a video might be the best way.

This video shows a user clicking a button to turn on and off the overlay widget, which appears when you click it. Inside the overlay are a number of list items, each with a button next to them. Some (like the readable font toggle) have a simple on/off button, while others, like font size, have a plus and a minus button.

The video demonstrates some of the functionality as follows:

• Toggle the overlay to open
• Turn on readable font
• Make text bigger and smaller
• Turn on link highlighting

How accessible is it?

I tried to navigate to the overlay using the keyboard, and while it was possible, it wasn’t the best experience for the following reasons:

• It’s at the end of the page, so you have to tab through all links to get to it
• Once opened, you have to leave it and re-enter it with Shift-Tab to get to the options inside it
• It doesn’t make the page more accessible

In conclusion

This was a fun little project but I’d have to conclude the following three points:

• Marketers have no business trying to code anything
• Marketers have no business trying to design anything
• Overlays are still terrible

Accessibility overlays, or “fix all your accessibility problems automatically with a couple of lines of code software” don’t make your website accessible. In fact, they’re no defense against accessibility lawsuits under the ADA – if you’re in the US.

So, what’s the alternative?

There’s only one, really. You need to find and fix your accessibility issues at source, whether that’s in code or in content. It’s the only way to make a better experience for everyone, which, when you’re building a website, should be your primary goal.

• Share via Twitter (opens in a new tab)
• Share via LinkedIn (opens in a new tab)
• Share via Facebook (opens in a new tab)
• Share via Email (opens in a new tab)

Large web teams are usually siloed with specific responsibilities. Developers handle the technical stuff like the architecture, navigation, and code, while content editors add all the words, pictures and, well, content.

But when it comes to accessibility, it’s not quite as clear-cut. Does responsibility for accessibility belong to developers or to content editors?

The answer really depends on who you talk to. Accessibility can be pretty technical. In fact, if you read through the Web Content Accessibility Guidelines (WCAG), you probably won’t understand it. Any content editor would look at it and tell you that it’s clearly a developer’s responsibility because of the jargon and the talk about web code.

(As an aside, here’s a video that explains WCAG in less than two minutes from our ‘Don’t be afraid of accessibility‘ series).

But developers only take care of building the site and its architecture. They’d tell you that they’re not responsible for the content that’s added to it. That’s usually either the marketing department or individual contributors’ responsibility.

So, who’s right?

The truth is, both are. Everyone’s responsible for accessibility.

What is content accessibility?

Content is made up of many individual components. Firstly, you have words and sentences. Then you have images. Then you have methods of presenting those, like a web page with headings and paragraphs, or PDFs and graphs or tables.

Each of these needs some consideration for accessibility.

Long, technical, and hard-to-read sentences make it more difficult for people to understand what you’re trying to say.

Images mostly require text descriptions (although, not always), which assistive technology users rely on to understand their contents. For example, screen readers read out the text on a page, including image descriptions.

Videos require captions, subtitles, and audio descriptions.

Text should be correctly formatted with semantic heading structure (basically, getting your headings in the right order). It’s vital to make a better experience for screen reader users and those navigating with a keyboard.

PDFs are basically terrible and you shouldn’t use them, but if you do, you should try your best to make sure they’re tagged correctly.

As you’ve probably gathered, all the items in this non-exclusive list are the things that content writers contribute to the website. So they don’t fall under the developers’ responsibility.

What is technical accessibility?

When people navigate your site using a keyboard, they get different feedback than if they were using a mouse. By pressing Tab on your keyboard, web browsers allow you to skip through each link on your page. They’ll also get a visual representation of where on the page they are by the use of focus states.

Here’s an example of the UK Government website showing a very obvious yellow and black focus state on a link.

Giving users a way to skip the top navigation completely makes for a more accessible experience. Nobody wants to be forced to tab through thirty menu items on every page just to get to the main content.

Here’s an example of a Skip to Content link on the US Government website. Note that this isn’t usually visible unless you are using keyboard navigation.

For menus, you should allow people to skip through the menu categories without being forced to open each menu item in each category in turn.

Users on mobile phones should be able to scroll up and down or side to side, but never both at the same time. Usually when content scrolls off the side of the page it’s because it’s not been constrained properly to fit the current screen size.

All these examples are things that developers can and should have control over, and equally are things that content creators do not.

How is your team organized?

In large organizations, there might be lots of content contributors. Most of these might not even be in the web team. For example, higher education institutions may have teaching or administrative staff with publishing rights, who add their own course content, PDFs, or tables to websites. This team structure would be known as ‘decentralized’.

The problem is that these contributors’ primary role is teaching and managing students. They’re not part of the web team and probably haven’t been exposed to web accessibility best practices (we wrote a book about that which you can download for free).

They might even assume that developers, being responsible for building the site, are also responsible for making it accessible.

The reality is that content accessibility shouldn’t be put in the same pile of fixes as technical accessibility.

If you run a decentralized team, where content editors publish their own articles without input from the development team, then each individual should make their content accessible first.

There is some nuance to consider here. If your website is managed centrally by a web team who approves all content before it’s published, then technically those people are responsible for making it accessible before they click ‘go’.

But if you’re in the content team, you can make it a lot easier for your web team by adding your alt text (here’s a guide to alt text) and running PDFs through Adobe and Word’s built-in accessibility checker before you hand it over.

For any other web content, use Silktide’s free accessibility checker to get an idea of where to start on a single page.

How can I get my content team to help me?

If you’re a web manager the first thing you should do is sit down with your content teams and let them know how they can help you.

Direct them towards our webinar, “Accessibility for content editors“, because it gives clear recommendations for making content accessible. We define areas of accessibility, explain how poor accessibility affects people, and give practical examples of how to make the content better.

Also, we have our free book “Best practices for implementing great web accessibility”, which is aimed at beginners to accessibility. It gives advice to content editors and developers alike. In it, we highlight the most common accessibility issues found on thousands of websites and explain how you can avoid them. Download the book for free here.

We’re happy to talk to you about your accessibility problems, so you can always request a demo of Silktide or find us on live chat here on our website.