Which tool is really the right fit for your business model?

The European Accessibility Act (EAA) has been in force in Germany since 28 June 2025. You can read more about this topic in the blog post Why companies should start checking their website for accessibility today.
Since then, demand for accessible websites has been rising – and the market for tools is growing just as fast. Anyone searching for ‘accessibility software for web agencies’ today will quickly find numerous tools, all of which sound promising – but are structured very differently.

So you can’t do without software support anymore – but which accessibility testing tools actually make sense for your agency? That depends on the question: what exactly do you want to offer?

We have systematically compared five relevant providers: decareto, IFDB, sitebrunch, Eye-Able and Silktide. No advertising, no affiliate links – just an honest assessment of which provider is best suited to which agency model.

First the question, then the tool

Before you decide on a tool, it’s worth clarifying three questions internally:

1. What are you selling – audits or remediation? Are you looking to offer and document accessibility audits as a service? Or do you also want to manage the operational implementation within your team?

2. Lots of small clients or a few complex projects? A freelancer with 30 SME clients needs something different from an agency with three enterprise accounts in the public sector.

3. Is the tool intended to boost internal productivity, or is it a product for clients? White-label capability, custom domains and automated report delivery are only relevant if you want to market accessibility as a managed service.

The five best providers of accessibility software at a glance

decareto – compliance platform with integrated data protection

decareto has grown out of the world of data protection and consistently applies that perspective to accessibility. The platform combines a GDPR check, a privacy policy generator and an accessibility audit within a single interface – making it one of the few solutions that truly offers data protection and accessibility as a seamless package.

What sets decareto apart from the competition

decareto uses software to scan entire websites, including all subpages – even those behind password protection and consent banners – in accordance with WCAG and BITV criteria. For agencies supporting clients with complex site structures, this is a crucial difference compared to tools that only provide random samples. Furthermore, the report contains prioritised recommendations for action with clear instructions for implementation.

The white-label platform is a true agency solution: reports can be created with your own logo, shared on custom domains and sent automatically to clients. Anyone wishing to market accessibility and data protection together as a compliance package will find a coherent, comprehensive offering here – GDPR checks, a data protection generator and accessibility audits all on a single platform.

Added to this is a pricing model that stands out from the competition: white-label reporting, custom domains, API, SSO and multi-site monitoring – from €34 per month for five websites, and in higher tiers from as little as €3 per website per month. Comparable features cost many times more with enterprise-focused providers or are simply not publicly priced.

Well suited for: Agencies and data protection officers who want to offer accessibility and data protection from a single source; scalable white-label audits with ongoing monitoring; anyone who needs enterprise-grade quality without an enterprise budget.

IFDB – Certification and legal protection

IFDB approaches accessibility from the perspective of compliance verification. The Access Suite combines an automatic initial scan, a manual audit using real users and assistive technologies, PDF remediation, real-time monitoring and – something the others do not offer – contractual protection against warning letters. It also offers a partner programme with comprehensive accessibility consultancy.

The reference frameworks are WCAG 2.2, BITV 2.0 and PDF/UA. For agencies serving clients in the public sector or highly regulated industries, this is a significant distinction. Pricing is modular and tailored to individual needs – there is no public price list, which makes costing more difficult, but this is not a deal-breaker for large projects.

Well suited for: Agencies acting as outsourcing partners for regulated clients, with formal reporting requirements or a need for PDF testing and certification.

sitebrunch – Operational team workflow

sitebrunch is particularly strong where several people are involved in implementing accessibility. Comments directly on the website, task allocation, exports to Jira, Notion and Asana, as well as guided manual checks with 96 verification steps, make it the most powerful tool for delivery teams.

Added to this are very affordable entry-level prices – from free to €149 per month for agencies – and an MCP server for AI-supported implementation workflows. White-label options are included in higher-tier plans. PDF validation against PDF/UA and WCAG is also included.

Well suited for: Agencies that organise accessibility internally as a team task and wish to feed results directly into existing project management workflows.

Eye-Able – Broadest operational scope

Eye-Able covers the widest range of features when it comes to day-to-day operations: an Assist widget for end users, AI-powered error correction for 26 error types, plain language, translations, PDF validation, Jira integration and manual testing with affected users. Validation is carried out against WCAG, EN 301 549, BITV/BFSG and other national standards.

This makes Eye-Able particularly appealing to agencies that wish to sell their clients not just audits, but genuine user support and implementation guidance as well. Prices are not publicly available – a 14-day trial is available free of charge.

Well suited for: Agencies with enterprise clients and a focus on implementation, assistance functions and content/language layers as part of their offering.

Silktide – Website governance beyond accessibility

Silktide is the most comprehensive platform in this comparison and goes far beyond accessibility: accessibility, content quality, UX, privacy/GDPR and analytics all run on a single interface. CMS integrations enable automatic retests following changes; AI provides context-based suggestions for improvement.

For agencies wishing to position accessibility as part of a broader website quality strategy – and whose clients manage large, heterogeneous web portfolios – Silktide is the most powerful tool. Pricing is bespoke, with most contracts running for at least 12 months.

Well suited for: enterprise governance, large multi-site portfolios, agencies with quality management requirements extending beyond accessibility.

How to evaluate an accessibility testing tool

Are you interested in a specific tool? Then don’t just test the scanner. Test the report and the workflow behind it. This is the only way to find out whether the tool can stand up to the demands of day-to-day agency work.

· Can reports be sent directly to clients or shared – under your own branding?

· Can results be communicated to developers or project managers in a meaningful and understandable way?

· How good is the accuracy of findings in real client projects?

· Is automated monitoring sufficient, or do you need guided manual checks or tests involving stakeholders?

Decision guide: Which scenario suits you best?

The biggest mistakes in tool selection occur when agencies only view the scan demo – and fail to check whether the results actually work in client meetings, during handover to developers and in reporting.

Conclusion

There is no single accessibility testing tool that is right for every agency. Anyone looking to scale accessibility as a white-label compliance product with data protection implications will find decareto to be a well-suited model – especially as the combination of a full domain scan, WCAG/BITV/BFSG checks and prioritised recommendations for action, at a price starting from €3 per website per month, is unrivalled in the market. Those who need regulated clients and formal certification are better off with IFDB. Those who primarily manage delivery teams will reach their goals faster with sitebrunch. Those who also sell implementation, support and language layers should try Eye-Able. And those who view website governance as an overarching strategy will find the broadest range of options with Silktide.

The crucial question isn’t: Which tool has the longest list of features? It’s: Which one fits with what you really want to sell to your clients?

Privacy policies become outdated over time

Websites are constantly changing: a new tracking tool is integrated, a tag manager is expanded, a YouTube video is added, a contact form is updated, or an external service is removed. This also affects which personal data is processed, which services are active, and what information website visitors must be provided with.

Many privacy policies are drafted once and then only reviewed sporadically. This is precisely where gaps arise. Data protection officers, agencies and compliance teams regularly face the same questions:

• Which external services are currently active on the website?
• Which cookies and scripts are being loaded?
• Which services are missing from the privacy policy?
• Which sections of text are out of date?
• Which content needs to be checked before publication?
• How can multiple websites, clients or language versions be managed efficiently?

Whilst the website continues to evolve, the privacy policy often remains unchanged. This is precisely what creates loopholes.

How a software-based data protection generator provides greater clarity

A privacy policy must reflect the actual data processing carried out on the website. This is precisely where the decareto Privacy Policy Generator comes in: it does not generate privacy policy texts in isolation from the website, but rather on the basis of automated website scans and the services identified during these scans.

The website scan gives rise to a controlled process for the creation, review and ongoing maintenance of privacy policy texts. For identified services, the privacy policy generator suggests suitable text templates. New, modified or discontinued services are highlighted before any changes are published.

The process is clearly structured:

1. Scan website: Automatically detects services, cookies, scripts and external providers used on the site.

2. Import detected services: The services identified during the scan are imported directly into the privacy policy generator.

3. Select suitable templates: Text blocks are available for detected services. You can also create your own templates or customise existing text.

4. Review and approve changes: New or removed services are highlighted. The suggested changes are approved manually.

5. Publish privacy policy: Once approved, the privacy policy can be published – via export or HTML snippet.

This means that privacy policy texts are not just created once, but are permanently traceable, monitored and maintained in multiple languages.

This is particularly relevant when new tools are regularly integrated, multiple websites are managed, clients use different services, or internal approval processes are required. Even with multiple language versions, the privacy policy generator ensures that content remains consistent and up to date.

The real added value therefore lies not merely in the rapid creation of a privacy policy. Ongoing maintenance is key: data protection officers retain control over content, versions, approvals and publications – and can reliably adapt privacy policy texts to the actual data processing taking place on the website.

Create multilingual privacy policies in 24 languages

The Privacy Policy Generator allows you to create, manage and regularly update privacy policies in 24 languages.

A particularly handy feature is that language versions can be generated at the touch of a button and managed centrally. Both decareto templates and your own privacy policy texts and custom templates can be automatically translated.

This saves time, particularly where privacy policies need to be regularly updated and made available in multiple languages. The benefits are particularly evident for international websites: new services are not only added to the main text but are also reliably incorporated into the relevant language versions.

Especially when dealing with multiple websites, clients or language versions, a central privacy policy generator ensures greater clarity, consistency and security throughout the entire maintenance process.

Over 300 text templates in German and English

decareto provides more than 300 text templates in German and English. These templates help to draft data protection texts more quickly and maintain consistency.

In addition, custom texts and templates can be stored and translated within the tool. This is important for teams that use their own standards, client-specific wording or internal approval processes.

This allows data protection teams to retain control over:

• Wording
• Language versions
• Text modules
• Approvals
• Updates
• Client-specific content

Key benefits

The decareto Privacy Policy Generator not only helps with the creation of privacy policy texts, but also with their management, review and updating.

• Up-to-date privacy policies: Use services identified during website scans as a basis
• 300+ templates: Both decareto templates and your own privacy policy texts and templates can be used and translated.
• 24 languages at the click of a button: Make it easier to provide privacy policies internationally
• Consistent texts: Uniform structure across websites, clients and languages
• Greater control: Changes are reviewed and published upon approval
• Ideal for teams: Particularly suitable for data protection officers, agencies and compliance teams collaborating on the decareto platform.
• Für wen eignet sich der decareto Datenschutzgenerator?

It is particularly suitable for organisations that need to maintain their privacy policies on an ongoing basis, rather than simply creating them once.

• Data protection officers
• Data protection consultants
• Web agencies
• Compliance teams
• Companies with multiple websites
• International organisations
• Law firms requiring regular website audits
• Teams with multiple clients or language versions

Privacy policies must evolve alongside the website

Websites are dynamic. Data protection texts should be too. The decareto Data Protection Generator helps you create privacy policies based on actual website scans, incorporate identified services, use suitable templates, review changes and publish texts in a controlled manner.

With the added feature of translation into 24 languages, the tool is particularly useful for international websites, agencies, data protection officers and compliance teams.

The greatest added value is realised where privacy policies need to be regularly reviewed, updated, translated and managed in a traceable manner.

A good privacy policy generator does more than just create texts. It ensures that privacy policies grow alongside the website.

Why traditional privacy policies are no longer sufficient today

A privacy policy is quick to draw up. However, it is only ever as up to date as the day it was created.

In practice, data protection risks often arise not from a lack of expertise or awareness, but from operational changes in day-to-day website operations:

• The marketing team is testing a new analytics tool
• An agency integrates a plugin
• An external service loads additional scripts
• A cookie is set without the text having been updated
• An old service has been removed but is still listed in the privacy policy
• A new service is active but does not yet appear in the privacy policy

The key question is therefore:

“Does our privacy policy still reflect what is actually happening on the website?”

With decareto, you can keep your privacy policies up to date at all times

The privacy policy generator uses software to analyse services identified during website scans, recognises relevant services and shows which content is already covered or needs to be added. This means you no longer have to research every service manually or piece together individual text modules. This saves time and reduces potential sources of error.

The privacy policy generator workflow

1. Scan the website

The privacy module scans the website and automatically identifies the services in use, such as analytics tools, tag managers, YouTube embeds or other external services. Manual research is generally not required.

2. Create a privacy policy

The services found are transferred to the privacy policy generator. For each service, the appropriate text block is suggested from a selection of over 300 templates and can be used straight away. The templates can be edited, customised and saved as your own templates.

3. Add standard content

In addition to the detected services, the privacy policy requires general content, such as:

• Data controller
• Data protection officer
• Data subjects’ rights
• Cookies
• Contact form
• General information on data processing
• …

This content can be prepared using templates and groupings, and can be edited and saved.

4. Reviewing changes

When decareto detects a new service, you will receive a notification that this has not yet been included in the privacy policy. Data protection officers can review the service directly and, if necessary, add it via drag-and-drop.

Services that are no longer in use are also automatically detected, so that outdated sections can be specifically removed. This ensures your privacy policy remains up to date at all times and corresponds to the services actually in use.

5. Publish changes

Changes to the privacy policy text are not published automatically but remain subject to review. New content only appears once it has been actively published. In this way, decareto combines automation with expert oversight.

decareto offers two methods for publishing the privacy policy, both of which can be flexibly adapted to different processes.

Export for approval and implementation

In many organisations, the data protection team’s work does not end directly in the CMS. Texts must be passed on to clients, agencies, web teams or internal stakeholders.

Exporting the privacy policy text as a Word file is ideal for this purpose. The privacy policy can be reviewed, checked and then handed over to the existing publication process.

HTML snippet for centralised maintenance

Alternatively, an HTML snippet can be embedded on the privacy policy page. Once approved, the content is made available via decareto and adapts to the website’s design.

Changes do not need to be manually replicated in the CMS each time. The privacy policy is maintained centrally, whilst publication remains under control.

To ensure reliable availability, the data is stored redundantly on high-availability servers. This ensures the privacy policy remains consistently accessible and is optimally protected against outages.

Why the decareto Data Protection Generator is particularly relevant for professionals

The decareto Data Protection Generator is aimed less at website operators who wish to generate a text on a one-off basis. It is of greater benefit to data protection officers, agencies and who regularly manage websites.

decareto is particularly helpful when:

• Multiple websites are managed
• Clients have different text standards
• Changes need to be reviewed in a traceable manner
• Privacy policies need to be updated regularly
• Website scans are already an integral part of the data protection process

Conclusion: Privacy policies must evolve alongside the website

The decareto Privacy Policy Generator is particularly useful for data protection officers, agencies and who not only need to create privacy policies but also keep them up to date on an ongoing basis.

The greatest benefit lies in the combination of website scanning, templates, monitoring and controlled publication. This makes the maintenance process more efficient, more traceable and easier to manage.

This means: less manual routine work, greater transparency regarding the services used, and a controlled process for updating data protection texts.

The result: less routine work, greater transparency and a privacy policy that remains more closely aligned with actual website usage.

Would you like to find out more about how decareto can help you optimise websites to ensure they are GDPR-compliant?

Book a demo or try decareto free for 14 days.

Why is keyboard operability important for accessibility?

Keyboard accessibility is necessary for several reasons:

• People with tremor, muscle weakness, limited fine motor skills or one-handed use cannot operate a mouse or can only do so with pain.
• Blind and severely visually impaired users mainly navigate with screen readers. This assistance software links its shortcuts (tab, arrow navigation, quick jump buttons, etc.) directly to the keyboard. Without a well-defined focus and controllable components, content simply remains inaccessible for them.
• Voice control (Dragon NaturallySpeaking, Windows speech recognition) and mouth/eye controls “pretend” to send keyboard commands. Only when a page is fully operable via buttons does it also work with these technologies.

Keyboard accessibility is closely linked to the “focus indicator” of the selected element. The focus identifies the currently active element on the page, and to make it easy to recognize, it must be clearly highlighted. In the two examples below, it is indicated by a border or a background color:

It is important that the focus is clearly emphasized for the following reasons:

• The visible focus shows where the user is currently located. Without this feedback, when navigating with the tab key (see below), you would not know which element will be activated next – this leads to confusion, incorrect entries or even abortion of the interaction.
• Keyboard events (Enter, spacebar, arrows, ESC …) only ever affect the currently focused element. If there is no focus – or it is “stuck” in the wrong area – interactions simply do not work.
• Screen readers link their output to the focus. If the focus changes, the screen reader reads the new context. A missing or invisible focus makes content practically impossible to find for blind users.

Which WCAG criteria relate to keyboard usability?

Requirements for accessible websites are specified in the internationally recognized standard“Web Content Accessibility Guidelines”. It is available in several versions (currently version 2.2) and several “conformance levels” (from A to AAA). The requirements are described in 86 so-called “Success Criteria”, the following table shows which of these are the relevant criteria for keyboard usability.

Use these steps to test websites for keyboard operability

Carry out an automatic test

Automated testing tools like decareto can identify some problematic aspects that prevent a website from being keyboard inaccessible:

• Missing HTML attribute tabindex="-1" for interactive element (this is required to ensure focus in a normally hidden element, such as a dialog popup).
• Missing or deleted focus, for example if the focus indicator is deliberately suppressed in a website for design reasons.

However, the majority of problems with keyboard operability require manual testing, which is described in the following sections.

Is there a link to the main content?

Open the page and click the Tab button once or twice. Does the focus first jump to a visible “To content” link?(WCAG 2.4.1).

Negative example: The page title gets the focus, but there is no skip link.

Navigate with the Tab key

Click Tab and Shift-Tab to navigate forwards or backwards. Is it clear which element has the focus and does the order follow the natural reading logic? Is nothing essential skipped(WCAG 2.4.3)?

Negative example: The focus jumps from the main navigation directly to the footer.

Check the focus indicator

Observe how the focus is identified. Is it easily recognizable? The indicator should be a line or area at least 2 px wide with 3:1 contrast(WCAG 2.4.7 & WCAG 2.4.11). The two screenshots at the top of the page show this clearly.

Negative example: The indicator is only a wafer-thin, gray outline or invisible on a dark background.

Fold-out menus

If the website has a navigation that can be opened (by clicking or hovering with the mouse), then these menus must be able to be opened with the keyboard.

Identify all navigation elements on the page that open a menu by hovering or clicking. Go to each menu item with Tab and try to open it with Enter or Pfeil-down / Pfeil-hoch. Does the focus remain in the open menu? Can it be closed with Esc?(WCAG 1.4.13, WCAG 2.1.1)

Negative example: The submenu only appears with a mouse hover, you cannot open or close it using the keyboard.

Check forms

Accessible forms can be operated using the keyboard:

• Switch between the form elements with Tab and Shift-Tab
• Selection of radio buttons with Pfeil-down / Pfeil-hoch
• Selection of a checkbox with Space
• Scroll through drop-down options with Pfeil-down / Pfeil-hoch
• Confirm a drop-down selection with Enter
• Close an open dropdown with Esc
• Send the form with Enter

Check whether all forms can be operated in this way(WCAG 2.1.1)

Check dialogs and pop-ups

Identify all dialogs that open as popups and are placed in front of the background. It must be possible to open and close them using the keyboard. Within an open dialog, it must be possible to reach all elements with Tab.

• Can the dialog be opened with Enter?
• Can it be closed with Esc?
• Does the focus jump to the dialog when opening?
• When using Tab multiple times, the focus must be “trapped” in the dialog.
• Does the focus return properly after closing?

Negative example: In a dialog, the focus must not suddenly switch to the side or even to elements behind the dialog when using Tab.

Check drag-and-drop actions

Drag-and-drop is occasionally used to reorder lists, for example. For operation with the keyboard, there must be an alternative to this, with which, for example, an element can be selected and the sorting is carried out using elements for “up” and “down”(WCAG 2.5.7)

For data protection officers, however, the means to examine a website for security vulnerabilities as part of an audit are limited – unless you are an expert in cyber security in your second job and know how to carry out a penetration test.

In this article, we describe an important aspect of website security, namely transport encryption, which is particularly relevant in connection with web forms. Surprisingly, this is often implemented only incompletely, although such vulnerabilities are easy to identify. Here you can find out how to check transport encryption.

What is transport encryption?

When we talk about transport encryption, we still very often use the colloquial term “SSL”, the acronym for Secure Socket Layer. This means that the data traffic between the browser and the web server is encrypted in such a way that no third party can intercept the data traffic.

These concerns are justified – the Internet’s decentralized architecture means that data packets often pass through a large number of servers before reaching their destination. Secret services take advantage of this and oblige the operators of the major Internet nodes to grant them full access.

The first protocol for encrypting data on the web was SSL, which was developed by Netscape in 1994. This version 1.0 was followed by SSL 2.0 and SSL 3.0, after which the acronym TLS (Transport Layer Security) was used for improved procedures, with the versions TLS 1.0 to TLS 1.3. Only the TLS 1.2 and 1.3 procedures should now be used, as all others are considered outdated and no longer secure enough.

However, the way it works has not fundamentally changed since 1994. It looks very simplified as follows:

1. The web server provides the browser with a digital certificate. This was issued by an independent body and proves the identity of the server – this prevents an attacker from standing in front of the web server, so to speak, pretending to be it and intercepting the communication.
2. The certificate also contains a so-called public key for an asymmetric encryption process. This means that the browser can encrypt a message with the publicly known key, but only the web server can decrypt it.
3. The browser and server also agree on which procedures are used for encryption in detail.

Vulnerabilities around transport encryption

For secure transport encryption, a website operator must not only provide a trustworthy TLS certificate, the web server must also be configured correctly – typically the task of a provider or IT service provider in a business context. The following errors should be avoided, also because they are easily recognizable by third parties:

Unencrypted server

Almost too banal for this list, but still common in the private sphere or in clubs. As certificates are now available free of charge (e.g. from Let’s Encrypt) and most web providers make them available at the touch of a button via an admin interface, it should actually also be common practice for this target group to use them.

Invalid certificate

With basic technical knowledge, it is easy to create a web server certificate yourself. However, as this has not been issued by an independent body, it is not sufficient to prove your own identity. In this case, browsers display such a clear warning that the website appears unusable.

A certificate is also invalid if it is installed on the wrong web server than intended. The warning message in the browser then looks similar.

Missing certificate chain

In order to be able to prove your identity, additional certificates should be installed on the server in addition to your own web server certificate, namely the so-called “intermediate certificates”. These identify the company from which the certificate was purchased. Modern browsers can reload these certificates; older browsers display an error if they are not available.

Expired certificate

As certificates are always issued with an expiration date (they are typically valid for 1 to 3 years), they become invalid at a certain point and must be renewed. In this case, web browsers also display a very extreme warning message.

Outdated protocols

The encryption details used are negotiated between the browser and server as described above. An attacker could suggest a very old and easy-to-breach method to the server. For this reason, servers should be configured in such a way that they only support modern, secure procedures.

Vulnerability to attacks

The known attack possibilities against TLS are mostly related to outdated protocols (e.g. POODLE is a vulnerability of SSL 3.0). One exception is the Heartbleed vulnerability, which has received a lot of press coverage since 2014. It is based on a bug in the OpenSSL software library,

No forced encryption

Even the best encryption is useless if it is not used. Websites should therefore redirect all calls made via http:// to https:// in order to enforce encryption.

Check the server encryption

Some of the vulnerabilities mentioned above are very easy to check because every browser displays a clearly visible warning message for some of them. However, this does not apply to all of them – the acceptance of old protocols, for example, is not readily apparent. Fortunately, there is a very powerful and free online tool that tests all of the above vulnerabilities – the SSLLabs website from Qualys.

Simply enter the server name you want to check in the input field and wait a few minutes. The result is then a very detailed check of a large number of criteria. The technical interpretation of the messages can be difficult, so the most relevant part for you is the summary at the top of the report – here using the example of https://decareto.com:

It is advisable to pass on all results with a rating lower than A to the website operator with a corresponding warning. The technical contact will know how to interpret the information, at least potential risks have been addressed.

If you scroll down in the report, you will also see the results for the potential problems with encryption mentioned above, such as the accepted protocols:

All protocols below (i.e. older) than TLS 1.2 should be marked with “No”, at least one of the TLS 1.2 or TLS 1.3 protocols should be marked with “Yes”.

1. Clean the browser history and let the consent tool (if there is one) appear.
2. Record cookies that were set without consent.
3. Identify the source and purpose of these cookies.

Dealing with consent management platforms

Consent tools have established themselves as the means of choice for obtaining consent on websites – and for giving website operators the good feeling that they are doing everything right when it comes to data protection. In fact, many websites still allow cookies through despite such tools, so it is worth taking a closer look.

Consent tools are available in very different price ranges and functionalities – some are simple open source scripts that are installed on the web server, while at the upper end of the price scale there are product suites, such as those from Usercentrics or OneTrust, which themselves run as complex external services on their own web servers. However, they all have the following simple basic principles in common:

• If a user has given consent, status information is saved in the browser (as a cookie or entry in the local storage). If you delete this information, you will appear as a user who has not yet given consent and the consent tool will be displayed again.
• Consent tools do not block cookies, but the services that set cookies. Therefore, consent tools use different mechanisms to load JavaScript tags (which represent external services) only after the user has given consent.
• The website operator can configure which scripts (and therefore cookies) are considered so essential that they are loaded immediately when the page is opened and which require consent in the consent tool.

Reset the history

Before you check a website for cookies, you should make sure that there are no old cookies that could falsify the result. The cookies in the browser may have a long lifespan and could therefore originate from a previous test – or in the case of third-party cookies even from the test of a completely different website!

In addition, a consent tool is initially no longer visible after it is closed – and even if you manage to open it again, it has often saved data, so it is better to delete the history for a new test for the sake of comparability. You can do this by specifically deleting cookies and data in the web memory:

• First open the website you want to examine and right-click in the content area. Select “Examine” to open the developer tools and then the app tab:

• Open the menu item “Local storage” and right-click on each sub-entry and then select “Delete” in the context menu.
• Repeat this for “Session storage” and “Cookies”.

What is “local storage”?

Local storage is a somewhat newer technology than cookies. It enables all common browsers to store and read data in the browser using JavaScript. The most important differences to cookies are

• Data from the local storage is not transferred to the server without being asked (even if this is of course possible with a request triggered by JavaScript).
• Data is retained until it is actively deleted.
• There are fewer restrictions on the amount of data – 5 million characters per domain, compared to approx. 4000 characters per cookie.

Local storage is also covered by the EU ePrivacy directive. You can view the written data in the app tab of the developer tools. There is also a menu item for “Session Storage” – this is based on the same technology as Local Storage, but the data stored there is deleted when the browser is closed.

Identifying cookies that were set without consent

Listing cookies without consent

With the following steps you can now determine which cookies are set by a website and whether this is done with or without consent:

• As a test example, open www.spotify.com
• Start the developer tools and open the “Application” tab
• Delete all entries in the menu for Local Storage and Cookies as described above
• Click on the menu item Cookies
• Load the page again.

You should now see the page with the content tool, like this:

Since you have not yet interacted with the consent tool to allow cookies, by definition all cookies you see have been set without consent. You can see three “1st party cookies”, i.e. cookies that have the same domain as the website.

If you click on the other areas in the menu, you will also find entries there, such as here under “Local Storage”:

In the case of our example website spotify.com, we have the following first-party cookies:

• OptanonConsent
• sp_landing
• sp_t

Also the following entry in the Local Storage from the domain www.google.com:

rc::a

How can you determine the necessity of a cookie?

The ePrivacy directive prohibits the setting of cookies (or entries in the web storage) that are not necessary for the operation of the website – unless consent has been given. The next step is therefore to determine whether the cookies found are technically necessary. This assessment can be complicated in individual cases (you can read more about this in our article on recognizing technically necessary cookies). However, this assessment is always based on determining the source of the cookies, such as the following:

• The web server software can set cookies, for example to establish a user session or to save status information such as the selected language. This web server software can be a store system such as Shopware or a content management system such as WordPress. In the case of WordPress, it could also be one of the many available plugins.
• If external services such as Google Analytics, Paypal or YouTube are used on a website, these also often set cookies.

It is often difficult to recognize the purpose of cookies set by the web server. It is easier to assess the necessity if a cookie comes from an external service: with a few exceptions (such as cookies from content banners), these cookies are not necessary.

To determine the sources, we use a search engine search. A search for “OptanonConsent cookie” quickly leads to the result that it belongs to the compliance solution “OneTrust”. We can therefore assume that it is necessary because it stores the status of consent.

The source of sp_landing and sp_t is less obvious, but the prefix “sp” could point to Spotify. A search actually shows the following result: “The sp_landing is set by Spotify to implement audio content from Spotify on the website and also registers information on user interaction related to the audio content”. Here, too, one could assume technical necessity.

The web storage entry rc::a is more interesting. A search for “rc::a cookie” leads to search results that lead to privacy statements of various websites in which Google is named as the source, with the purpose “This cookie is used to distinguish between humans and bots. This is beneficial for the website, in order to make valid reports on the use of their website.”

A look at the “Network” tab of the developer tools shows calls to Google servers with the path “www.google.com/recaptcha”:

In fact, Google ReCaptcha is known as an external service to distinguish between humans and “bots” and to prevent bots from accessing the website – so obviously the entry rc::a in the web store is set by Google Recaptcha, and one can now at least argue about the technical necessity.

Is accessibility a legal requirement?

In Europe, the websites of public institutions must be accessible; this is defined in the “Web Accessibility Act”. This is transposed into national law by the European member states. From June 2025, the accessibility obligation will also apply to the private sector, as the European Accessibility Act (also transposed into national law) will then apply.

In the USA, website accessibility is stipulated by the Americans with Disabilities Act, which has been in force since 1990 and provides for severe fines.

Are there other reasons to make a website accessible?

It is not only advisable not to exclude people with disabilities from using your website due to legal obligations or compliance. Rather, it is in the company’s own interest to design accessible websites for a whole range of other reasons.

Increasing the reach

The European Commission estimates that 87 million people with disabilities will benefit from the European Accessibility Act. An accessible website is available to people with visual, hearing or motor impairments, thereby increasing its reach and potentially also its customer base.

Improved usability

The accessibility requirements not only benefit people with disabilities, as they enforce consistent navigation, clearly visible buttons and a clean structure. This leads to better usability for everyone.

Better SEO-Ranking

Google and other search engines prefer accessible websites. This is due to the following reasons:

• Good usability leads to a lower bounce rate and longer dwell time
• A clear structure of the HTML code makes it easier to crawl and index the content
• Accessible websites are designed for use with screen readers, which improves your visibility in voice searches
• Search engines appreciate conformity to standards such as WCAG
• Accessibility often also means shorter page load times, which benefits SEO

Strengthening image and brand perception

If your company takes inclusion and accessibility seriously, it will be perceived as responsible and progressive. This is particularly important for companies above a certain size or in regulated markets.

Which companies are required to make their website accessible?

The European Accessibility Act applies between traders and consumers and affects both products and services. They are affected in the following cases, among others:

• If you are a manufacturer, importer or retailer of digital products such as smartphones, ebook readers, ATMs or internet-enabled televisions.
• If you provide services such as telephone services or passenger transportation. In particular, “electronic commerce” is affected, which means not only online stores but also bookings of all kinds (including online appointment bookings) and comparable interactions.

The law provides for some exceptions, for example with regard to content that was created before the deadline of June 28, 2025, and under certain conditions it does not apply to “micro-enterprises”; if in doubt, you should consult a lawyer.

If a website is operated by a public body, or if something can be purchased or a business transaction can be initiated on the website, then it must presumably be implemented in an accessible manner.

What does accessibility on websites mean?

Non-accessible websites exclude people with a visual impairment in particular:

• Blind people use screen readers that read out the content of a website. In Windows, the “Narrator” is pre-installed, in MacOS there is “Voiceover”. Interaction takes place via the keyboard without the aid of a mouse. The website must be programmed in such a way that this is possible without any problems, as many elements in websites make it difficult to use screen readers (such as sliders and links and images without comprehensible labels) or must be specially adapted for this, such as input forms. Keyboard operation also benefits people with motor impairments.
• People with severely impaired vision may not need a screen reader, but they do need the ability to enlarge the text on the page, which does not work on all pages, and they need sufficient contrast in the color scheme.
• Blind and deaf people can only use videos if there is a transcript or subtitles.

Other accessibility requirements include simple language (for people with a cognitive impairment) or the use of color (for people with a red-green impairment).

The generally used and internationally accepted standard for accessibility on websites is described in the “W3C Web Content Accessibility Guidelines”, which are currently available in version 2 and are based on 13 guidelines.

1. Perceptible
   1. Provide text alternatives for all non-text content so that it can be changed to other forms required by the user, such as large print, Braille, symbols or simpler language.
   2. Provide alternatives for time-based media.
   3. Create content that can be presented in different ways (for example, with a simpler layout) without losing information or structure.
   4. Make it easier for users to see and hear content, including separation between foreground and background.
2. Operable
   1. Ensure that all functionalities are available from the keypad.
   2. Give users sufficient time to read and use content.
   3. Do not design content in ways that are known to cause seizures.
   4. Provide means to help users navigate, find content and determine where they are.
   5. Make it easier for users to use input devices other than keyboards.
3. Understandable
   1. Make text content readable and understandable.
   2. Make web pages look and function predictably.
   3. Help users to avoid and correct errors.
4. Robustness
   1. Maximize compatibility with current and future user agents, including assistive technologies.

The effort required to implement or adapt a website in accordance with the guidelines should not be underestimated, we will go into more detail in the following articles. The WCAG provides for three levels of conformity (A to AAA), which require varying degrees of effort to implement.

How can a website be checked for accessibility?

Checking a website for accessibility should always be a combination of manual and automated tests – in this regard, it’s similar to checking for data protection compliance.

Automated tests can check technical aspects and the programming of the website in particular, i.e. topics such as color contrast, alternative texts, keyboard operation, etc. Since clean programming in compliance with the WCAG standards is crucial for accessible use, many errors can be found very quickly through automation.

On the other hand, certain errors can only be poorly detected by automated tests, such as whether all navigation elements can be reached via the keyboard, whether alternative texts make sense, or whether the visible order on the page corresponds to the structure of the HTML code.

A good evaluation by automated tests is therefore a necessary, but not a sufficient condition for accessibility.

Free accessibility testing tools include WAVE (https://wave.webaim.org/) or Lighthouse, which is part of the developer tools in every Chrome browser. Such tools can be used to test individual pages, but they do not provide any information on which errors are found on multiple pages and do not allow continuous monitoring.

These options are currently only available with very high-priced products. From 2025, decareto Compliance Monitoring will offer automated testing of an entire website at a fraction of the cost of comparable tools.

1. Lack of Access to Legal Information and Unclear Data Processing

A common mistake in consent banner design is that access to the imprint and privacy policy is blocked or restricted before the user has given their consent. However, according to Articles 13 and 14 of the GDPR, this information must be freely accessible at all times, without requiring consent. Users must be able to access information about data processing before making a decision.

Additionally, the purpose of data processing must be briefly and clearly communicated in the banner. Detailed information, such as which personal data is affected, what happens to it, and who has access, can be provided via a link to the privacy policy.

Tip: Ensure that the imprint and privacy policy are always linked in the website’s footer and accessible without consent. Alternatively, you can include a clearly visible link directly in the consent banner. The banner itself should contain a brief explanation of the processing purpose, e.g., “We use cookies for analytics and personalized advertising,” and link to the privacy policy where detailed information is available.

Picture 1. an example that showcases all necessary informations

2. Misleading Design (Dark Patterns)

Another frequent issue with cookie banners is the use of dark patterns. Those are deceptive design elements that subtly push users toward giving consent. Often, the “Accept” button is visually emphasized, while options like “Reject” or “Customize settings” are harder to find or less prominent. This can create the impression that consent is the only reasonable choice.

However, according to Article 7 of the GDPR, consent must be given freely. This means the user must have a genuine choice, without being influenced by the design. If the banner makes it difficult to decline, the consent is not voluntary and therefore invalid.

Tip: Present all options equally. “Accept,” “Reject,” and “Customize settings” should be the same size, visible, and easily accessible so that the user can make an informed decision.

Picture 2. an example for dark patterns

3. No Granular Cookie Selection

Under Article 6 of the GDPR, users must not be forced to accept all cookies in general. They must be given the option to choose between different categories of cookies, such as necessary, functional, and marketing cookies. However, many cookie banners only offer the options to “Accept all” or “Reject all,” which is insufficient.

Tip: Provide users with a clear option to choose between different cookie categories. Clearly explain the purpose of each category so users know exactly what they are consenting to.

Picture 3. an example with clear options to choose between different cookie categories

4. Vague or Misleading Headlines

In addition to the required information, the language and visual design of the cookie banner play a crucial role. According to Article 12 of the GDPR, information must be presented “in a concise, transparent, intelligible and easily accessible form.” However, many banners use vague headlines such as “We respect your privacy” or “To improve your user experience,” which do not adequately inform users about the implications of their consent.

Tip: Use clear and precise headlines that directly inform users about what will happen to their data.

Picture 5. + 6. picture 5 is an example with an unclear title and the title in picture 6 is clear with its intent.

5. No Easy Way to Withdraw or Modify Consent

According to Article 7 (3) of the GDPR, users have the right to withdraw or modify their consent at any time. However, many cookie banners either do not offer this option or make it difficult to find.

Tip: Include an easily accessible way to change cookie settings, for example, via a permanent link in the website’s footer. The process of withdrawing or adjusting consent should be just as simple as granting it.

Picture 7. access to the consent layer through the website footer

6. Privacy-Friendly Default Settings

Under Article 25 of the GDPR, systems must be configured by default to process only the minimum amount of data necessary. Many cookie banners, however, set cookies by default or have pre-checked boxes for consent, which violates the GDPR.

Tip: Avoid pre-set cookies or pre-checked consent boxes. Users must actively give consent (Opt-in) before non-essential cookies are activated. Only technically necessary cookies may be used without consent.

Technical Implementation of the Cookie Banner

In addition to visual design, the technical implementation of the cookie banner must not be overlooked. A common mistake is setting non-essential cookies or using external services for which consent is required, before the user has given their consent. This violates Article 6 of the GDPR, Article 25 of the TDDG, and the ePrivacy Directive.

Use tools like decareto to ensure that no cookies are loaded without prior consent. This helps ensure that the technical implementation of your website complies with GDPR requirements.

Sources:

https://www.baden-wuerttemberg.datenschutz.de/faq-zu-cookies-und-tracking-2/#43_wie_gestalte_ich_einwilligungs-banner

https://www.hh-datenschutz.de/fileadmin/mustervorlagen/Handreichung_Cookie-Consent-Banner.pdf

https://www.lfd.niedersachsen.de/download/161158/Datenschutzkonforme_Einwilligungen_auf_Webseiten_-_Anforderungen_an_Consent-Layer_PDF_-_nicht_vollstaendig_barrierefrei_.pdf

https://www.verbraucherzentrale.nrw/sites/default/files/2023-05/lg_koln_vom_23-03-2023_33_o_376_22_geschwaerzt.pdf

Shopify is a cloud-based e-commerce platform that allows merchants to create and operate online stores without any programming knowledge. Shopify takes care of hosting and administration. Shopify stores can be easily expanded with accounting, logistics, marketing or legal security functions via an ecosystem of external “apps” that can be integrated into your own store.

Shopify Inc. is a Canadian company and has its headquarters at 151 O’Connor Street, Ground floor, Ottawa, Ontario, K2P 2L8. Shopify operates online presences for over 2 million merchants, the Shopify App Store contains 13,000 apps.

Shopify operates online presences for over 2 million merchants, the Shopify App Store contains 13,000 apps.

Is Shopify GDPR compliant?

For an assessment of GDPR compliance, it is relevant, among other things, in which countries Shopify processes personal data, whereby not only the locations of the data centers, but also the headquarters of the companies involved must be taken into account.

Shopify is a Canadian company and uses the Google Cloud Platform (USA) as its hosting infrastructure. In addition, the content delivery network of the company Cloudflare (also USA) is used for scaling.

Data processing is generally only permitted for countries in the EU or for those for which there is an adequacy decision. This is the case for Canada. For the USA, there is an adequacy decision for companies that are certified in the EU-US Data Privacy Network. Cloudflare and Google are both certified in the DPF (as of 05.08.2024), so their use is initially legally permissible.

However, Shopify stores practically always use additional external services, some of which also process personal data or set cookies and are therefore relevant for the assessment of GDPR compliance.

For GDPR-compliant use, additional obligations must also be fulfilled (see below).

Does Shopify set cookies?

Shopify states that it uses the following cookies:

How to check external services and cookies in a Shopify store?

An essential part of the GDPR compliance of a Shopify store is the use of a consent banner so that users can give legally compliant consent. Before this has been given, no services that require consent may be loaded and no cookies may be set that are not necessary for the operation of the store.

If apps are used in the store, connections to the app operator’s web server are often established and the apps may also set cookies. An assessment must be made on a case-by-case basis.

Ideally, the store should not make any network calls to servers that do not belong to Shopify without consent, i.e. to domains other than

• Your store domain
• shopify.com
• shopifycdn.com
• shopifycloud.com
• shop.app

Which of Shopify’s cookies can be considered technically necessary is controversial, but of those mentioned above, at most the cookies _identity_session, checkout and user should be set without consent.

To carry out these checks, we recommend using an automated solution such as decareto Compliance Monitoring, as manual checks are usually difficult to implement. In addition, the use of marketing measures in online stores requires permanent and regular monitoring.

How to use Shopify in compliance with the GDPR?

The legally compliant use of Shopify is not trivial, especially due to the use of apps that may also process personal data. The following points, among others, must be observed

• Adaptation of the privacy policy
• Use of a correctly configured consent banner
• Conclusion of contracts for commissioned data processing with Shopify and the operators of the apps

We recommend seeking external data protection advice for this.