AXECC: Benchmarking the Privacy and Accessibility Impact of Browser Extensions
James Clarke, Maryam Mehrnezhad, Ehsan Toreini · 2026 · ACM Transactions on Privacy and Security · doi:10.1145/3805701
Summary
This paper presents AXECC, a novel automated framework for jointly measuring the web-tracking behaviour and accessibility impact of browser extensions at scale. The authors argue that while browser extensions are widely installed to improve the browsing experience, including by disabled users who rely on accessibility-focused add-ons such as in-browser screen readers, magnifiers, contrast changers and dark-mode tools, they also introduce significant privacy and accessibility risks that have not previously been studied together. AXECC combines static analysis of each extension's manifest.json (permissions, hosts, manifest version, content and background scripts) with dynamic analysis in an instrumented Chromium browser (VisibleV8) using Puppeteer to automate browsing of controlled test pages the authors call HoneyPages. Network traffic is captured with mitmproxy and compared against tracker blocklists (EasyList, EasyPrivacy, AdGuard), cookies are attributed to extensions via the Cookie Database, and JS API calls are logged and filtered for known fingerprinting and tracking APIs. In parallel, accessibility is evaluated by running WAVE and Google Lighthouse on each HoneyPage before and after each extension is loaded, allowing the authors to attribute changes in errors, contrast errors, alerts, WAVE features, structural elements and ARIA landmarks directly to individual extensions. The authors applied the framework to 21,344 real-world extensions scraped from all 18 Chrome Web Store categories in June 2024, across a baseline login-style page and four WordPress HoneyPages (index, login, blog, 404).
Key findings
15.97% of extensions (3,344 of 21,304), with a combined user base exceeding 600M, perform third-party tracking within 60 seconds of page load. Google domains account for 64.78% of tracking requests, followed by Microsoft, Facebook, Yandex and Cloudflare. Tracking is heavily category-dependent: Games (63.33%), Shopping (24.05%) and Workflow/Planning (22.98%) extensions track most often, with Games extensions averaging ~2,031 JS API calls and some extensions issuing more than 150 distinct trackers. Notably, the top tracking Accessibility-category extension, Turn Off the Lights, sent 464 tracking requests across HoneyPages. On accessibility, 3.31% of extensions altered the HoneyPages in some way, affecting around 65M users: 2.03% worsened accessibility (chiefly by adding images without alt text, empty buttons and empty form labels, with 2,424 missing-alt-text instances) while 1.92% improved it (primarily dark-mode and contrast-enhancing extensions fixing contrast and language attributes). Extensions that alter accessibility request more permissions (3.7 vs 1.9), make more JS API calls (1,372 vs 448), and send more trackers (2.96 vs 1.64) than those that do not, indicating that intrusive DOM manipulation correlates with tracking intensity. Manifest V3 extensions, despite being positioned as more privacy-respecting, exhibited a higher proportion of tracking than V2.
Relevance
For accessibility practitioners, this work reframes browser extensions as a dual-purpose risk surface: the same add-ons users install to make the web usable, including screen-reading, magnification, dark-mode and reading-assistance tools, can silently degrade page accessibility for themselves and others, or leak fine-grained behavioural data. The authors invoke the concept of differential vulnerability: disabled users install accessibility extensions more than non-disabled users, so privacy harms and broken ARIA, labels or contrast land disproportionately on them. Practical implications include: treat extension recommendations (including dark-mode and contrast tools) as accessibility and privacy decisions, not just UX choices; audit extensions with both Lighthouse/WAVE and network inspection before deploying them in assistive contexts; and push for Chrome Web Store vetting, clearer permission disclosures, and accessibility-aware extension guidelines. Limitations include reliance on automated tooling (no real-user interaction), static HoneyPages, a single UK vantage point, and no usability evaluation.
Tags: browser extensions · web tracking · privacy · accessibility testing · automated testing · WCAG · WAVE · Lighthouse · dark mode · screen readers · assistive technology
Standards referenced: WCAG · ARIA