What Your Cookie Scanner Misses: localStorage, IndexedDB and Fingerprinting

Many organizations rely on a “cookie scanner” to inventory trackers and prove compliance. It’s a helpful starting point—but it can create a false sense of security. Modern tracking and personalization often happens outside traditional cookies, using localStorage, IndexedDB, service workers, and increasingly fingerprinting. If your governance program only looks for cookies, you can miss what matters most: what the site actually does, and whether users—including users with disabilities—can understand, consent to, and control it.

This isn’t just a privacy issue. Under WCAG and inclusive design principles, consent and privacy controls are part of the user journey. If the banner, preferences center, or “do not sell/share” mechanisms are confusing, keyboard-trapping, or not readable by assistive technology, users can’t exercise meaningful choice.

Why cookie scanners miss modern tracking

Traditional cookie scanners typically detect HTTP cookies set by the browser and sometimes identify common third-party scripts. But several widely used tracking patterns don’t show up as “cookies” at all:

• Web Storage: localStorage and sessionStorage store persistent identifiers and preference flags.
• IndexedDB: a structured database in the browser, used for offline apps and also for storing identifiers or syncing state.
• Cache-based tracking: ETAGs, cache keys, or service worker caches can be abused for re-identification.
• Fingerprinting: identification using device/browser characteristics (fonts, canvas, audio, screen size, etc.) without storing a classic identifier.

From an accessibility perspective, what matters is the user impact: are people being tracked before they can consent, and can they actually interact with the consent interface? If the consent UI is inaccessible, some users may be tracked by default simply because they can’t opt out.

localStorage: invisible IDs and inaccessible preference logic

localStorage stores key/value pairs that persist until cleared. It’s commonly used for:

• Remembering consent choices (e.g., “marketing=true”).
• Persisting user IDs for analytics or A/B testing.
• Saving UI state that can affect content presentation.

The accessibility risk isn’t localStorage itself—it’s how teams use it. For example, a consent banner may visually appear “rejected,” but the underlying stored value might still enable non-essential scripts. Or the site may store the “banner dismissed” state, meaning users never see the consent prompt again—even if they didn’t make a clear choice.

Inclusive design means ensuring consent states are transparent and reversible. If your preference center is behind a tiny icon, lacks a clear name, or isn’t keyboard reachable, users who rely on keyboard-only navigation or screen readers may never find it. For WCAG-aligned guidance on the user interface itself, see How to Make Your Cookie Banner Accessible: WCAG 2.2 Requirements for Consent.

IndexedDB: powerful storage that can bypass “cookie” assumptions

IndexedDB is a browser database designed for complex web apps (offline support, caching, large datasets). Because it’s not a cookie, many scanners and compliance checklists overlook it. But it can store:

• Persistent identifiers used for analytics attribution.
• Event queues that upload later (even after the banner is closed).
• Personalization profiles or segmentation data.

What’s the accessibility angle? Two common scenarios:

• “Consent gating” that isn’t real gating: The UI suggests that tracking is off until consent, but events are buffered in IndexedDB and sent later if the user accepts—or worse, regardless of acceptance.
• Preference flows that are hard to use: If opting out requires multiple modals, tiny toggles, or controls without programmatic labels, users with motor, visual, or cognitive disabilities are disproportionately impacted.

A good practice is to treat any client-side storage used for tracking as part of your consent scope, and validate behavior with real interaction testing—not only automated scans.

Fingerprinting: when there’s nothing to “scan” in storage

Fingerprinting can identify or single out users based on signals such as installed fonts, canvas rendering, audio processing, device memory, language settings, or screen characteristics. Some approaches store minimal data locally, which means a cookie-only audit may show “nothing.”

From a compliance and accessibility standpoint, fingerprinting introduces two major issues:

• Notice and choice: If users can’t understand that fingerprinting is happening—or can’t access the control to limit it—consent becomes meaningless.
• Dark patterns and cognitive load: Overly technical explanations or “accept-only” designs can violate inclusive design expectations even when the UI is technically keyboard-accessible.

This is where consent implementation details matter. Platforms adopting consent frameworks should consider how their setup impacts assistive technology users. For example, Google Consent Mode v2: Basic vs Advanced, and Why the Difference Matters for Accessibility explores how configuration choices affect user experience and clarity.

WCAG: what applies to consent, preferences, and privacy UX

WCAG doesn’t “ban tracking,” but it does require that interactive controls be perceivable, operable, and understandable for everyone. Cookie banners and privacy centers often fail common success criteria, such as:

• Keyboard accessibility (2.1.1): Can users tab to every control, including “Reject,” “Manage preferences,” and close buttons?
• Focus order (2.4.3) and focus visible (2.4.7): Does focus move logically, and is it clearly indicated?
• Name, role, value (4.1.2) / 4.1.3 in WCAG 2.2: Do toggles and buttons expose correct labels to assistive tech?
• Labels and instructions (3.3.2): Are categories like “Functional” vs “Strictly necessary” explained in plain language?
• Reflow and target size (1.4.10, 2.5.8): Are controls usable on mobile and at 200–400% zoom?

It’s also important to plan for renewal and record keeping in a way users can understand and revisit. Consent shouldn’t be a one-time, hard-to-find moment; it’s an ongoing control. For timing and retention considerations, see How Long Does Cookie Consent Last? Renewal Periods and Record Keeping.

How to audit beyond cookies (and include accessibility)

If you want to know what your scanner missed, combine technical inspection with accessibility checks:

1) Inspect browser storage directly

• Use DevTools to review Application storage: localStorage, sessionStorage, IndexedDB, service worker caches.
• Look for identifiers, timestamps, marketing flags, or “consent” keys that don’t match the UI state.

2) Test real user flows with assistive technology

• Navigate the banner and preferences using keyboard only.
• Check with a screen reader (NVDA/JAWS/VoiceOver) that toggles announce correctly and changes are confirmed.
• Verify that “reject all” is as easy as “accept all,” and that choices persist as expected.

3) Validate tracking behavior before and after consent

• Use network monitoring to see whether requests fire prior to consent.
• Confirm that opting out actually stops non-essential requests, rather than buffering and sending later.

4) Monitor for regressions

Consent interfaces change often (new vendors, updated CMP scripts, redesigns). Ongoing monitoring helps prevent accessibility regressions that lock users out of privacy controls. Corpowid (corpowid.ai) can support this with automated accessibility audits and monitoring that flag common WCAG issues in modals, dialogs, and interactive controls—areas where consent banners frequently fail.

Inclusive consent isn’t optional—it's product quality

When privacy controls are inaccessible, the impact is real: users who can’t perceive or operate the consent UI lose agency. That’s a product failure, not just a legal risk. The same mindset that drives accessibility in other regulated experiences applies here too—clear disclosures, usable controls, and consistent behavior. For example, expectations around disclosure show up across digital products, as discussed in Movie Ticket Apps Must Disclose Accessibility Features for People with Disabilities; transparency and usability go hand in hand.

Practical checklist: what to fix this week

• Inventory storage beyond cookies: Document localStorage keys and IndexedDB databases used by analytics, A/B testing, chat widgets, and ad tech.
• Align UI and behavior: Ensure the visual state (“off”) matches actual network behavior and stored values.
• Make preferences easy to reach: Provide a clearly labeled “Cookie preferences” link in the footer and in the accessibility statement or privacy page.
• Remove interaction traps: No keyboard traps, no focus loss behind overlays, no unlabeled toggles.
• Use plain language: Explain categories and consequences without jargon; avoid coercive design.

Cookie scanners are a useful baseline, but they’re not the full map. By auditing localStorage, IndexedDB, and fingerprinting—and ensuring consent experiences meet WCAG expectations—you reduce compliance risk and build a more trustworthy, inclusive experience. Tools like Corpowid (corpowid.ai) can help teams catch accessibility failures early and keep consent and preference interfaces usable as the site evolves.