Start here
Before You Fix It: What This Check Means
Consent UI should give people clear accept/reject choices and an easy way to change preferences later. In plain terms, people should be able to accept, reject, and later change consent settings easily. Scavo evaluates three baseline controls.
Why this matters in practice: this signal influences reliability, trust, and diagnosability of your production setup.
How to use this result: treat this as directional evidence, not final truth. This result reflects what was observable at scan time and should be verified in your own production context. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Ensure consent UI loads consistently on intended public routes. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Your cookie consent banner makes it harder to reject than to accept, violating GDPR's requirement for equal choice.
The EDPB requires that cookie banners include an equally conspicuous "Reject All" button on the first layer — making rejection as easy as acceptance (EDPB Cookie Banner Taskforce Report, 2023). CNIL fined Google €150M specifically because acceptance required one click while rejection required five. Both French and Spanish authorities treat a missing reject button as a violation.
What Scavo checks (plain English)
Scavo evaluates three baseline controls:
LC-T1: is a consent surface visible when it should be?LC-T2: is there practical accept/reject parity?LC-T3: is there a visible path to manage or withdraw preferences later?
How the logic behaves:
- if no surface is detected and non-essential pre-consent tracking is observed, this is a strong failure signal
- if accept exists but reject does not, this fails parity
- if no manage/withdraw path is detected, this fails manageability
- inconclusive states can appear when browser interaction probing fails
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for legal_consent_interface, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
legal_consent_interface - Category:
LEGAL_COMPLIANCE
Why fixing this matters
People need real control, not decorative controls. If reject/manage paths are weak, trust drops and support/legal escalations increase.
From an engineering perspective, this check usually exposes UX-to-runtime mismatches: banner copy says one thing, tag behavior does another.
If you are not technical
- Test the live banner yourself: can you clearly accept, reject, and later change your mind?
- Check mobile experience too, not just desktop.
- Ask your team for a short proof clip showing reject and manage flows.
- Re-run Scavo after fixes and confirm controls improve.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Legal consent interface (legal_consent_interface). Please ensure consent surface visibility, accept/reject parity, and a persistent manage/withdraw path. Provide runtime evidence for each control and re-run Scavo.If you are technical
- Ensure consent UI loads consistently on intended public routes.
- Implement explicit reject equivalent to accept in visibility and effort.
- Provide a persistent settings entry point (footer/account/help) for preference changes.
- Keep CMP state synchronized with tag-manager and app runtime logic.
- Cover SPA reload/navigation paths so controls remain effective after first interaction.
How to verify
- In a clean session, confirm banner appears where expected.
- Confirm accept and reject are both available and actionable.
- Confirm a later "manage preferences" path works after first visit.
- Re-run Scavo and review
LC-T1,LC-T2, andLC-T3outcomes.
What this scan cannot confirm
- It is not a legal opinion for every jurisdiction.
- It does not replace manual UX/accessibility review.
- It may be inconclusive when automated interaction probing cannot complete.
Owner checklist
- [ ] Assign owners for consent UX and runtime enforcement.
- [ ] Keep consent interaction tests in release QA.
- [ ] Review parity and manage-path after CMP/theme updates.
- [ ] Track regressions by template/route class.
FAQ
Is having only an "Accept" button enough?
No. This check expects practical parity so people can reject as clearly as they can accept.
What counts as a manage/withdraw path?
Any clear, persistent route that lets users change prior choices after the first visit.
Can this warn if banner appears only on some pages?
Yes. Page-scope checks can reveal route-level inconsistency.
Why can results be inconclusive?
If browser automation cannot fully execute banner interactions, Scavo marks uncertainty instead of guessing.
Sources
- EDPB Guidelines 05/2020 on Consent
- ICO: Cookies and similar technologies
- CNIL cookies guidance
- GDPR text (EU 2016/679)
This guide is operational guidance, not legal advice.
