"The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except when:" is the whole of Success Criterion 2.5.8, Target Size (Minimum), before its exceptions begin.1 It sits at Level AA in WCAG 2.2, the W3C Recommendation of 12 December 2024, and carries five exceptions.1 One of them, Inline, decides how the rule applies to an ad inside a sentence.2 Before the exception comes a plainer problem: the pointer a phone reader brings to a page cannot hover.
Hover is a desktop event, and a phone does not have one
MDN's page on the hover media feature says it tests "whether the user's primary input mechanism can hover over elements."3 Its value "none" covers a device that "cannot hover at all or cannot conveniently hover."3 The example given is the handheld: "many mobile devices emulate hovering when the user performs an inconvenient long tap," and that emulation is what "none" describes.3 A desktop reader resting the pointer on an underlined word sends an event a phone has no ordinary way to send.
Words already in a publisher's articles get a light dotted underline, and the small panel that opens from it is the bubble. On a desktop the bubble opens after a short hover delay and closes on mouse-out or the Escape key; from a keyboard, Enter on the focused word opens it. On a phone the embed, adbubbles.js, gives the first tap the role of the hover. A tap on the underlined word opens the bubble, and a tap anywhere outside closes it. Only a second tap, on the link inside, follows that link. The first touch on an ad word therefore opens a panel and cannot leave the page.
What leaves the page is the same on every device. The embed sends three beacons. One view is sent per page load, one open when a bubble has been visible for one second, and one click when a link is followed. AdBubbles sets no cookie, stores no identifier, and collects no personal data from readers.
Apple and Google set a larger minimum than the W3C
WCAG's 24 CSS pixels is a minimum, and Apple and Google publish larger numbers in their own units. Apple's design tips tell designers to "Create controls that measure at least 44 points x 44 points so they can be accurately tapped with a finger."4 Google's Android accessibility guidance asks for at least 48x48dp per touch target.5 It adds that "A touch target of 48x48dp results in a physical size of about 9mm, regardless of screen size."5
One study measured thumbs directly. Parhi, Karlson, and Bederson tested twenty participants on a touchscreen handheld, in a study presented at MobileHCI 2006.6 Error rates showed no significant difference once a single-tap target reached 9.6 mm.6 The authors concluded that 9.2 mm for single-tap tasks and 9.6 mm for sequences of taps "should be sufficiently large for one-handed thumb use on touchscreen-based handhelds."6 Google's figure of about 9mm is within a millimeter of both.5
An underlined word inside a sentence is the target the standard exempts
The Inline exception reads: "The target is in a sentence or its size is otherwise constrained by the line-height of non-target text."1 An underlined word that the embed marks is text inside the publisher's paragraph, set in the publisher's own font and line-height. The 24-pixel minimum does not apply to it.1 The link inside the bubble is different: a control in a panel, rendered inside a Shadow DOM where the publisher's CSS cannot affect it. It is the kind of target the criterion is written for, and an accessibility audit measures it like any other control.
"The intent of this success criterion is to help ensure targets can be easily activated without accidentally activating an adjacent target," the Understanding document says.2 The readers it names are "Users with dexterity limitations and those who have difficulty with fine motor movement."2 Adjacency, not size alone, is the hazard the W3C describes. The embed never places two bubbles in the same paragraph, and it skips links. An ad word therefore never sits inside a link that already has a destination.
Seeing how this looks on a given site costs nothing. A publisher account and the embed cost nothing to set up, and the installation notes describe the scope setting and the per-page maximum. A site added to the account shows which of its words are currently for sale before any bubble runs.
Google already treats the accidental tap as a policy problem
Google's ad placement policies for AdSense tell publishers to "Be careful when placing links, play buttons, download buttons, navigation buttons near ads because they might lead to accidental clicks."7 The Google Publisher Policies prohibit Google-served ads that "overlay or are adjacent to navigational or other action items and may lead to unintended ad interactions."8 Both describe the touch in the W3C's intent statement: a touch meant for one target that lands on another. A policy page can only ask a publisher to be careful; a format determines what a first touch does.
Google's remedy for placements that keep producing such clicks is Confirmed Click. Its help page describes it as "a Google Ads product feature that adds a confirmation to ad placements that may be generating accidental clicks."9 A reader who taps such an ad "will be asked to confirm their intent to visit the advertiser page by clicking a button associated to an action, such as 'Visit site.'"9 On those placements Google no longer treats one tap as evidence of intent, and it inserts another after the fact.
A bubble has that second tap by design rather than by remedy. The first tap opens a panel carrying an "Ad" label, a headline of at most forty characters, and a body of at most ninety characters. Also in the panel are the advertiser's display domain, one link, and a small "Ads by AdBubbles" mark. The second tap, on the link, is the click, and every link in a bubble carries rel="sponsored noopener".
What the embed knows about that second tap is only that it happened. AdBubbles matches words on a publisher's pages to an advertiser who bought them for the month. The readers who see a bubble are whoever opens the page, the embed follows none of them to another page or site, and no result is promised to the advertiser. A click beacon records that a link was followed and nothing about why.
A first tap cannot enlarge a word set in small type
The Inline exception also means the underlined word takes whatever size the publisher's typography gives it. Suppose a site sets its paragraphs at 14 pixels with a line-height of 20 pixels on a phone. The underlined word is then no taller than its 20-pixel line, under the minimum the criterion sets for other targets. It is excused only because it is inline. Nothing in the exception changes the thumb that has to land on it.
The embed adds a dotted underline to a bought word and changes nothing else about the type. The word stays in the publisher's own font, at the line-height the theme set. A publisher whose pages are hard to tap on a phone will find the underlined words as hard to tap as the links around them. The scope and the per-page maximum decide how many underlined words a page carries. Neither makes a word larger than the type it is set in.