Use an HTML5 banner interaction when it answers a small shopper question: which option to choose, which tradeoff matters, or what optional extra is available. The three examples below show the information before and after each action, including what should happen when a preview fails or data is missing.
Try three original, self-contained teaching demos for a fictional brand: a product selector, an attribute comparison, and an offer reveal. You can also open the complete demo index.
The central decision is simple: use interaction only when it helps someone complete a small, relevant task inside the available space. Let a shopper choose an option, compare a tradeoff, or reveal genuinely optional information. Do not add gestures merely to manufacture activity.
The products, prices, and offer dates are fictional teaching data. These browser demos illustrate interaction design; they are not ad-network upload packages.
First, check what kind of “example” you are looking at
An HTML5 label does not prove that the media in front of you is a working HTML5 unit. A showcase may expose only a poster image or send you to a video host. For example, NEXD’s page for its Urban Outfitters hotspot concept labels the displayed asset as a still and says the concept was created for illustration rather than as a live campaign. Celtra’s rich-media roundup links several examples to Vimeo. Both pages can help with discovery; neither medium, by itself, lets a researcher reproduce the ad’s internal input-to-response sequence. See the NEXD example page and Celtra’s rich-media examples.
Even an authoring interface is not the same as a rendered ad. Google Web Designer’s documentation says its Swipeable Gallery shows only the starting frame on the stage and should be previewed in a browser to see the fully rendered component. That distinction matters: implementation evidence, rendered behavior, and network acceptance are three separate layers. See The Swipeable Gallery component.
A useful inspection record needs four things:
| Question | What to record |
|---|---|
| What was initially visible? | Product, selected option, terms, loading state, fallback, and CTA |
| What input was actually applied? | Tap, click, keyboard activation, drag, or hover—not an inferred gesture |
| What visibly changed? | Selected state, text, image, comparison, disclosure, or error message |
| What opened a destination? | The exact CTA or exit boundary, including whether an internal control also navigated |
If you cannot perform the input, describe the reference as a still, recording, provider description, or inaccessible preview. That is more useful than filling the missing sequence with an imagined interaction.
Choose the shopper task before the visual effect
The three demos use the same fictional product family, but each interaction solves a different question.
| Interaction | The question it should answer | Information that should already be visible | Warning sign |
|---|---|---|---|
| Product selector | “Which option do I prefer?” | Product identity, stable attributes, current selection, price basis | Every swatch exits the ad, or the image and selected label disagree |
| Attribute comparison | “What tradeoff am I making?” | Both products and a common set of values | A carousel forces the reader to memorize one product while viewing another |
| Offer reveal | “What optional extra is available?” | Price, scope, material conditions, and deadline | Essential terms are hidden behind a scratch, spin, or click |
The static alternative remains the control. If three product colors can be understood more quickly as three labeled thumbnails, a selector may add friction rather than information. If two products fit in a legible table, animating them through separate slides may make the comparison worse. Interaction earns its place when the visible response clarifies the decision.
Example 1: A product selector whose latest choice wins
Open the product selector demo. It uses a 300×250 canvas for a fictional “Daypack 18” priced at $48, with 18-liter capacity and Slate, Moss, and Clay color options. Changing a swatch stays inside the unit. Only the “View sample product” CTA crosses the destination boundary.
The visible behavior is straightforward, but the important design problem is asynchronous consistency. Imagine that the Moss preview takes 460 milliseconds to arrive while Clay takes 300 milliseconds. A person taps Moss, then quickly taps Clay. If the Moss response returns last and blindly updates the image, the ad displays a Moss pack beside the label “Color: Clay.”
The demo prevents that with a monotonically increasing selection number. Each request remembers the number that existed when it started. A response may update the preview only when it still matches the current selection.
selectionId = selectionId + 1
requestId = selectionId
selectedColor = newColor
when preview finishes:
if requestId != selectionId: ignore it
otherwise: render selectedColor
This is a small example of a larger rule: the rendered product, selected control, visible label, and CTA state must describe the same choice. Do not treat the image as decoration that may lag behind the decision.
The failure state follows the same rule. When the Clay preview is deliberately made unavailable, the demo keeps “Color selection: Clay” visible and shows an unavailable-preview treatment. It does not fall back to a successful Moss image, because that would silently misrepresent the selection. Reset returns the unit to Slate. With JavaScript disabled or initialization unavailable, the default product information remains readable and the inactive controls do not pretend to work.
A selector is useful when an option creates a meaningful visual or configuration change that the reader can evaluate in place. It is unnecessary when the options are too similar to perceive, the response takes longer than the decision deserves, or the ad cannot keep internal controls separate from the click-through area.
Example 2: A comparison that explains a tradeoff without hiding the table
Open the attribute comparison demo. It places two fictional products on a 300×600 canvas. The complete values are visible from the start:
| Attribute | Daypack 18 | Trekpack 24 | Difference |
|---|---|---|---|
| Capacity | 18 L | 24 L | Trekpack has 6 L more |
| Weight | 520 g | 760 g | Daypack is 240 g lighter |
| Price | $48 | $64 | Trekpack costs $16 more |
The Capacity, Weight, and Price controls do not filter out a product or move it to another slide. They highlight one row and translate the arithmetic into a sentence. That gives the interaction a narrow job: direct attention to a tradeoff without making the underlying evidence disappear.
The same data produces different choices when the shopper’s constraints change:
| Fictional requirement | Daypack 18 | Trekpack 24 | Result |
|---|---|---|---|
| At least 22 L and no more than $65 | Fails capacity | Passes both | Trekpack fits |
| No more than 600 g and no more than $50 | Passes both | Fails both | Daypack fits |
| At least 22 L and no more than 700 g | Fails capacity | Fails weight | Neither fits |
“Neither” is a valid result. A comparison tool should not invent a winner simply because the layout contains two product cards. It should also avoid turning missing data into zero. In the demo’s missing-weight fixture, Trekpack’s weight becomes “Not provided,” and the weight difference becomes unavailable; capacity and price remain usable. In an equal-price fixture, the result is a tie rather than a fabricated advantage.
This is where interactive comparison can outperform a decorative carousel: it preserves a common denominator. Both products remain visible, the units remain fixed, and the explanation can be checked against the numbers. If the interaction instead makes a reader remember the first item while swiping to the second, it has introduced memory work rather than reduced it.
Example 3: Reveal the extra, not the offer itself
Open the offer reveal demo. This 300×600 example starts with the important commercial information already visible: one fictional Daypack 18, a sample price reduction from $48 to $36, the 25% calculation, the merchandise-only scope, the exclusion of tax and shipping, a fixed simulation date, and a fixed deadline.
The arithmetic is explicit:
- $48 × 25% = $12 off
- $48 − $12 = $36
The reveal button exposes only one optional extra: “Demo code: DEMO25 — not redeemable.” The CTA remains available without revealing the code.
This boundary matters because a reveal can easily become a toll gate. Requiring a scratch, spin, or click before showing the actual price may generate activity while making the offer harder to evaluate. A defensible reveal leaves the decision-critical information outside the gate and uses the interaction for supplementary detail.
The demo also treats time as data rather than theater. Its active fixture uses a simulation date of November 15, 2026 and a deadline of November 30, 2026 at 11:59:59 p.m. UTC−05:00. Reset hides the code; it never extends the deadline or creates a fresh discount. In the expired fixture, the reveal control is disabled and the message says that no redeemable code exists. A separate invalid-data fixture illustrates an “Offer unavailable” state rather than a negative price, $0, or a made-up code. The fixture selects that state explicitly; it does not parse or validate a live offer feed.
The reveal control is a native button with a visible expanded state. The WAI-ARIA Authoring Practices disclosure pattern describes Enter and Space activation plus aria-expanded for a show/hide control. This demo uses a separate Reset button rather than claiming exact conformance to every disclosure-pattern detail, but the state remains explicit. See the Disclosure pattern.
Input, loading, and fallback are part of the interaction
A polished normal state is not enough. An interactive banner has to decide what happens before scripts are ready, when an asset fails, when a person changes an input quickly, and when the input method is not a mouse.
The WCAG keyboard guidance says functionality should be operable through a keyboard interface unless the task depends on the path of movement. The Dragging Movements guidance separately calls for a single-pointer alternative to dragging, subject to its stated exceptions. That means adding arrow buttons or tappable choices to a swipe or drag experience may serve a different requirement than keyboard support; one does not automatically prove the other.
Pointer activation needs a cancellation story too. The Pointer Cancellation guidance favors completing an action on the up-event, with a way to abort or undo where appropriate. In practical banner terms, pressing a CTA and moving outside it before release should not surprise the user with a destination. Internal controls should not sit beneath a global exit layer that treats every attempt to choose, reset, or reveal as a click-through.
For each interaction, write the non-ideal states before production:
- Meaningful initial HTML: show a real product name, useful values, and a clear default before enhancement.
- Initialization failure: leave the information readable and controls inactive rather than displaying buttons that do nothing.
- Asset failure: retain truthful text and selection state; do not substitute a mismatched product image.
- Rapid input: define whether the latest input wins, whether a transition queues, and what happens at the last item.
- Reset: return to a known state without changing prices, deadlines, or hidden business data.
- Small host: do not shrink long terms and controls until they are technically present but practically unreadable. Use a different layout or size when the task no longer fits.
- No drag or hover: provide a tap/click route to the same information when the interaction does not inherently require a traced path.
The demos use native controls and visible focus styling. A production version still needs input and accessibility checks in its actual host, including keyboard use, touch, screen-reader output, text zoom, and contrast.
A browser demo is not an uploadable HTML5 ad
The files in this article demonstrate state behavior. They intentionally do not claim to be Google Ads packages. Converting a browser prototype into a deliverable means satisfying the exact campaign and upload route, not merely zipping a page that works locally.
For one concrete environment, Google’s current uploaded display specifications list both 300×250 and 300×600 among supported HTML5 sizes and set a 600 KB maximum for the uploaded HTML5 ZIP. For “other HTML5 ads,” the document requires an ad.size meta tag, relative references to bundled resources, no more than 40 files in the ZIP, and UTF-8 for non-ASCII text. It also says Google Web Designer creatives must use the Google Ads environment, that images should be local to the ZIP, and that expandable ads and local-storage methods are not supported. See Uploaded display ads specifications, checked September 8, 2026.
Click handling is especially important for these demos. The specifications page lists Tap Area among supported Google Web Designer components. Yet Google’s uploaded-ad error guide says that when an ad receives the “modifying clickability” error, a Tap Area should be removed from a Google Web Designer build; it says the whole ad then becomes clickable, while describing a dynamic-remarketing exception. The same guide rejects multiple exits. See Fix error messages with Uploaded ads.
Those pages should not be flattened into either “Tap Area always works” or “Tap Area is universally forbidden.” They describe context-sensitive requirements and an error-remediation path. For a product selector, this distinction can change the concept: if every tap becomes an exit, swatches cannot function as internal choices. The correct next step is to validate the exact package and campaign route, then inspect the real ad-server preview. A component appearing on a support list is not the same as an accepted build.
Use three separate gates:
| Gate | Question |
|---|---|
| Browser behavior | Does the selector, comparison, or reveal produce the intended state? |
| Package validation | Does the ZIP meet this environment’s dimensions, files, assets, APIs, and click rules? |
| Delivery acceptance | Does the actual account, campaign, ad server, publisher, and review process accept and serve it correctly? |
Passing one gate does not mark the others complete.
More interaction is not evidence of better advertising
Interaction can be useful without being universally more effective. A 2022 PLOS ONE scoping review searched English-language original research from 1997 through February 17, 2021 and included 32 studies published in 33 articles across several interactive-ad formats. In nine studies that examined relationships between interactivity features and outcomes such as recall or comprehension, findings were mixed. The review did not perform a risk-of-bias assessment or quantitative synthesis, and the formats, populations, and measures varied, so it is not a banner-performance benchmark. It is strong evidence against treating “more interactive” as an automatic result. See The impact of interactive advertising on consumer engagement, recall, and understanding.
Even simple rates can tell different stories depending on the denominator. Consider a fictional test with 100 exposed people in each version:
| Version | People who reveal | People who answer correctly | Correct among revealers | Correct among everyone exposed |
|---|---|---|---|---|
| A | 50 | 40 | 80% | 40% |
| B | 90 | 54 | 60% | 54% |
Version A looks better if the denominator is only people who revealed. Version B reaches a larger share of everyone exposed. Neither table says anything about purchases, incremental lift, or profit. The point is that “engagement rate,” “interaction time,” comprehension, click-through, and conversion are different outcomes. Define the event, numerator, denominator, exposure window, and business question before interpreting activity.
Choose the smallest interaction that adds information
A useful HTML5 banner interaction has a short sentence behind it:
- “Choose the option and see the same product update.”
- “Select the priority and understand the tradeoff.”
- “Read the offer, then reveal an optional extra.”
Build the truthful initial state first. Keep internal controls separate from the CTA. Specify rapid input, loading, reset, expiry, missing data, and no-script behavior before polishing motion. Then validate the browser behavior, package contract, and delivery environment as separate jobs.
The best interactive banner is not the one that collects the most gestures. It is the one that gives the reader one useful piece of decision-making power without hiding the evidence or creating an accidental exit.
Sources
- Uploaded display ads specifications — Google Ads Help; checked September 8, 2026.
- Fix error messages with Uploaded ads — Google Ads Help; checked September 8, 2026.
- The Swipeable Gallery component — Google Web Designer Help; checked September 8, 2026.
- Understanding Success Criterion 2.1.1: Keyboard — W3C Web Accessibility Initiative; checked September 8, 2026.
- Understanding Success Criterion 2.5.2: Pointer Cancellation — W3C Web Accessibility Initiative; checked September 8, 2026.
- Understanding Success Criterion 2.5.7: Dragging Movements — W3C Web Accessibility Initiative; checked September 8, 2026.
- Disclosure (Show/Hide) Pattern — W3C WAI-ARIA Authoring Practices Guide; checked September 8, 2026.
- The impact of interactive advertising on consumer engagement, recall, and understanding: A scoping systematic review for informing regulatory science — PLOS ONE; published February 3, 2022; checked September 8, 2026.
- Hotspot Urban Outfitters — NEXD; checked September 8, 2026.
- Rich Media Ads: 5 Attention-Grabbing Examples from Top Brands — Celtra; updated January 5, 2026; checked September 8, 2026.




