Skip to content

Test your website now

Free, no card. We read only public pages.

Run free audit →

Compliance · High severity

No Reject All Button on Cookie Banner: Provide a Genuine Refusal Route

Review acceptance without a direct refusal option. Apply relevant authority guidance, test rejection, and distinguish initial refusal from later withdrawal.

Published · Updated

What the check tests

Check
comp.consent.reject-first-layer - Refusal available in the first layer of the dialog
Passes when
Actions inside the dialog are classified by their accessible name against a Czech, English and German lexicon. An action matching nothing is reported as unclassified rather than dropped.
Scope
graded on every page crawled
Severity
High
Fix effort
medium - a working day
Impact when fixed
high

In one paragraph

No reject all button on cookie banner means the observed first layer contains a recognised acceptance action without a recognised refusal. Provide a clear genuine choice where consent is sought and test what refusal actually does. European authority guidance strongly supports a refusal option alongside acceptance, subject to the applicable framework. This language-based snapshot does not prove every missing match is unlawful or that every matched reject button works.

Why it matters

Valid consent must be freely given, specific, informed, and unambiguous under the relevant GDPR standard. A design that pushes users toward agreement while hiding alternatives can undermine meaningful choice.

The EDPB Cookie Banner Taskforce reported a broad majority view against missing refusal options on layers with consent buttons, while noting some differing authority positions and additional national rules. Its later cookie-pledge correspondence expressly supported a first-layer reject opportunity. Do not turn that into a claim of one identical statutory button phrase across every country.

Initial refusal and withdrawal after consent are separate moments. GDPR Article 7(3) specifically requires withdrawal to be as easy as giving consent; it is not, by itself, a literal HTML requirement for a particular first-layer button label.

How WebAuditOS evaluates this finding

The supplied rendered-dialog rule classifies visible actions through an English, Czech, and German lexicon with its documented normalisation and refusal-first priority. Recognised acceptance without recognised refusal fails at high severity; a matched pair passes the presence test.

No recognised acceptance, absent or unreadable dialog, tracking without a dialog, and unrendered pages have separate conditions. Unrecognised languages or a close icon can be misclassified. The check does not click the controls or establish effective blocking, valid consent, or lawful consequences of refusing.

How to fix it

  1. Reproduce the first visit without a stored choice and inspect the actual dialog and technologies. Determine whether consent is needed for the relevant operations before redesigning its controls.
  2. Make acceptance, refusal, and any granular settings understandable. Use clear labels appropriate to the interface language rather than a vague Continue action whose legal effect is unclear.
  3. Provide an effective direct refusal path alongside the acceptance route under the applicable guidance. Do not treat a settings link alone as equivalent merely because refusal might be several steps away.
  4. Test actual rejection in a fresh context. Inspect storage and requests before interaction, after refusal, on navigation, and on later visits. A button named Reject all must implement its stated choice.
  5. Keep withdrawal accessible after consent and distinguish it from initial refusal. A settings link or another suitable mechanism can support later changes if it is easy to find and actually applies the new state.
  6. Review close behaviour explicitly. Do not silently treat dismissal, scrolling, or continued browsing as a consent grant. Nor should users have to guess that an unlabeled X means reject.
  7. Test keyboard and touch access, readable wording, language variants, and representative dialog states. A lexicon miss needs manual review, not automatic replacement of a correct local-language label.
  8. Rescan presence, defaults, prominence, and technical behaviour checks separately. Keep jurisdiction-specific legal review distinct from a green technical result.

What the fix can break

Changing labels without changing behaviour can make the interface more misleading. Synchronise the CMP, tags, stored choices, and explanatory text.

A refusal route hidden behind inaccessible settings is not a practical choice. Review focus and assistive interaction rather than only pointer screenshots.

Do not frame a detector failure as a definitive infringement notice to another operator without verifying its actual facts and applicable legal context.

Questions

Is withdrawal the same as first-time rejection?

No. Both matter, but Article 7(3)'s specific rule concerns withdrawal after consent.

Does a matched reject label prove tracking stops?

No. The supplied check does not activate the control. Verify actual behaviour.

Can a valid local-language action be missed?

Yes. The rule's fixed lexicon has limited language coverage.

Review button prominence, preselected options, and the cookie consent guide.

Standards and sources

  • ePrivacy
  • § 89 odst. 3 ZEK
  • GDPR Art. 4(11)
  • GDPR Art. 7

In the report

Test this on your own site

Every scan runs comp.consent.reject-first-layer on every page it crawls, on every plan. The finding carries this id, so a line in a report can be matched to the explanation above - and the free scan needs no account.