EU ePrivacy Directive Cookie banner UX test cases

Start each test run by classifying the technologies loaded on the page. Article 5(3) is triggered when the service stores information on, or gains access to information already stored in, a user's terminal equipment unless a narrow technical or strictly necessary exemption applies.

Do not limit the inventory to browser cookies. EDPB technical-scope guidance covers storage and access patterns such as JavaScript-triggered network calls, tracking pixels, tracked URLs, local storage, application identifiers, and some IP-based or device-derived signals when they originate from terminal equipment.

Open the page in a clean browser profile and inspect the first banner layer. If the layer offers an accept-all action for non-essential cookies, the test should look for a comparably available refuse, reject, or continue-without-accepting action at the same decision point.

The EDPB Cookie Banner Taskforce treated missing reject options and designs that push users toward consent as core banner issues. The test should therefore evaluate placement, wording, contrast, keyboard focus order, and whether refusal keeps the user on the requested content without non-essential storage or access.

Click into the settings layer and inspect every purpose, vendor, and technology toggle. Consent-required purposes should start off by default; the user's active selection should be needed before those purposes are enabled.

The test should also check granularity. If analytics, advertising, personalization, social plug-ins, and A/B testing are bundled behind one switch, the evidence should explain whether each purpose is being accepted separately or whether a single toggle is forcing consent to unrelated purposes.

After accepting non-essential cookies, test whether the same user can find a persistent route to change or withdraw consent. The route can be a footer link, privacy settings control, account setting, or CMP icon, but it must be available without unusual effort and without lowering the service level.

The withdrawal test is not complete when the UI flips a toggle. It should also confirm that consent-dependent tags stop, future reads or writes are blocked, downstream suppression signals are sent where used, and any deletion or retention behavior is documented.

Load a page that uses a blocking overlay, paywall-like consent gate, or content-hidden-until-accept pattern. The test should check whether the user can access the requested service or content without consenting to non-essential storage or access.

Do not convert this into a national-law rule. The grounded EU-level test is narrower: when access to a service or functionality is conditional on consenting to terminal-equipment storage or access that is not necessary for that service, the consent-choice record is weak because the user lacks a genuine choice.

Analytics requires its own test because teams often misclassify it as necessary. First-party audience measurement may be lower risk, but it should not be treated as exempt unless the implementation matches documented conditions such as limited audience-measurement purposes, no cross-checking with other processing, single-publisher scope, IP truncation, limited tracker lifetime, user information, and an objection mechanism.

When those conditions are not met, analytics should behave like any other consent-required purpose: off before consent, controlled by a clear toggle, blocked after rejection, and stopped after withdrawal.

The final test is whether the organization can prove what the user saw, what the user chose, and what the technology did as a result. A correct-looking banner is not enough if the team cannot reconstruct the consent workflow at the time of the session.

Keep the evidence minimal but sufficient. EDPB consent guidance supports keeping records that show how consent was obtained, when it was obtained, what information was presented, and how the workflow met the criteria for valid consent.