In one paragraph
Pre-ticked cookie consent boxes means the observed consent interface contains enabled choices the rule treats as optional and already selected. Consent cannot be inferred from silence, inactivity, or a preselected opt-in. Start consent-dependent purposes off until an appropriate affirmative choice, while distinguishing a previously valid saved choice and genuinely exempt operations. Labels such as functional and locked-on controls do not, by themselves, prove necessity.
Why it matters
GDPR Recital 32 rejects pre-ticked boxes as a way to establish consent. The EDPB taskforce confirmed the same position for cookie opt-ins. A visitor saving unchanged preselected optional categories has not supplied the affirmative choice that a genuine opt-in requires.
Actual necessity depends on the operation and requested service. A disabled toggle can describe a necessary preference or authentication operation, but can also misleadingly lock an optional tracker on. A category name is not a legal exemption.
An existing valid preference and an initial default are different states. The implementation should honour an appropriately established choice without pretending that every checked box on a return visit was necessarily preselected without consent. Test a truly fresh context separately.
How WebAuditOS evaluates this finding
The supplied rule inspects selected checkboxes and switch roles within the detected dialog, including some hidden descendants. It skips its documented disabled controls and necessary-sounding names before evaluating checked state.
Eligible checked optional candidates fail at high severity; no such candidate can pass, including a dialog with no toggles. Unreadable, absent-with-tracking, or unrendered cases can be ungraded. Separate preference panels and inaccurate functional classifications create blind spots. The rule does not legally classify all purposes or prove underlying behaviour follows the UI.
How to fix it
- Inventory purposes, vendors, storage or access, and subsequent processing. Determine what actually needs consent rather than applying the CMP's default taxonomy unreviewed.
- Reproduce a fresh first visit with no existing choice. Inspect visible and hidden settings, whether they are part of the detected dialog or a separately rendered panel.
- Set genuine optional consent categories off by default and require an appropriate affirmative grant. Do not silently restore a previous broad preference when no valid record or applicable state exists.
- Review locked necessary groups separately. Document why each operation qualifies for an exemption under applicable rules; neither disabled nor a functional label establishes that fact.
- Distinguish consent from other processing or objection controls where they exist. Legitimate interest for subsequent personal-data processing is not an alternative legal basis for terminal storage/access that requires consent.
- Test save, reject, accept by category, reopening, withdrawal, and navigation. Verify actual cookies, storage, and requests rather than only the toggle graphics.
- Keep the interface accessible, with meaningful names, real states, and complete keyboard interaction. An inaccessible custom switch can misrepresent what the user selected.
- Rescan and review separate or dynamic panels manually. A no-toggle pass or hidden unclassified category is not proof of lawful defaults across the whole service.
What the fix can break
Removing a preselection can change analytics or personalisation behaviour. That is not a reason to retain a purported grant the visitor never made.
A display-state fix can leave backend or tag-manager defaults permissive. Synchronise the operational state with the actual choice.
Do not erase a valid previously stored refusal or grant merely to make every screenshot look initially unchecked. Manage lifecycle, purpose changes, and withdrawal appropriately.
Questions
Are necessary-sounding names enough to justify preselection?
No. Review the operation and actual applicable exemption.
Does a disabled optional tracker become necessary?
No. Disabled is a UI property, not a legal classification.
Can a saved valid preference legitimately be shown as selected?
It can be a different situation from an initial preselected opt-in. Verify the prior choice and the processing context.
Which related checks help?
Review direct refusal, button prominence, and the cookie consent guide.