⏱️ Lectura: 10 min
The button that says “Accept All” in the cookie banner of an online store in Buenos Aires is, character for character, the same one that appears on a blog in Berlin or a fintech in Bogotá. This isn’t plagiarism in the traditional sense: it’s what designer Anatoly Zenkov called stolen buttons in his essay Stolen Buttons, the practice of copying and pasting interface copy without anyone ever redesigning it.
📑 En este artículo
- TL;DR
- What Happened
- Context and History of Stolen Buttons
- Technical Details: Why the Copy Repeats
- How to Audit Your Own Site’s Buttons
- Impact and Analysis
- What’s Next
- Frequently Asked Questions
- What does “stolen buttons” mean in interface design?
- Why do almost all cookie banners say “Accept All”?
- Is using the same text on every button an accessibility problem?
- What does WCAG say about button text?
- How do I audit my own site’s buttons?
- Are design systems like Material Design or Bootstrap to blame?
- References
Zenkov gathered dozens of screenshots of consent banners, login forms, and subscription popups with the exact same text, often in different languages mixed on the same page. The result is a web where buttons say less and less about what each action actually does.
TL;DR
- The concept of “stolen buttons” was coined by designer Anatoly Zenkov in his essay Stolen Buttons.
- The most repeated pattern is “Accept All” / “Reject All,” standardized by consent frameworks like the IAB Transparency and Consent Framework.
- The “Continue with Google” and “Continue with Facebook” buttons replicate the exact text required by each OAuth SDK’s brand guidelines.
- W3C’s WCAG criterion 2.4.4 (Link Purpose) requires that a button’s text describe the action, not a repeated generic label.
- Design systems like Material Design and Bootstrap ship components with default text that teams rarely override.
- Auditing a site’s own buttons can be done with a short JavaScript script in the browser console, no installation required.
What Happened
Zenkov’s article isn’t a conventional essay: it’s largely a raw collection of interface fragments pulled from dozens of real sites. The same list mixes “Akzeptieren,” “Reject All,” “Registrieren Sie sich jetzt,” “Anmelden,” “Save,” and “Accept & Close.” That mix of languages is the visual proof of the central argument: the same eight or ten button patterns repeat regardless of the site’s language or industry.
The list includes cookie consent buttons (“Accept All,” “Reject All,” “Decline”), authentication buttons (“Log In,” “Sign Up,” “Continue with Facebook”), shopping cart buttons (“Buy Now,” “Add to Cart”), and newsletter subscription buttons (“Register Now,” “1 month trial”). None of them were designed specifically for the site where they appear: they all come from a template, a consent framework, or a design system that the product team integrated without touching the text.
Context and History of Stolen Buttons
The phenomenon has a fairly clear origin date for its most visible case: cookie banners. The General Data Protection Regulation (GDPR) took effect on May 25, 2018, and forced thousands of European sites, and any site with European visitors, to request consent before installing third-party cookies. Most of those sites didn’t design their own consent flow: they adopted a consent management platform (CMP) that already came with the text worked out.
IAB Europe standardized that flow with the Transparency and Consent Framework (TCF), which defines not only what data gets shared but, in practice, which buttons and visual hierarchy most CMPs on the market use. That’s why “Accept All” and “Reject All” appear with the same visual weight on sites that have nothing else in common.
Something similar happens with social login. When a site integrates the Google Identity Services SDK or Facebook Login, those platforms’ brand guidelines require using literally the text “Continue with Google” or “Continue with Facebook,” with a fixed logo and button style. It’s not negligence on the product team’s part: it’s a contractual requirement from the OAuth provider.
Technical Details: Why the Copy Repeats
The technical cause of stolen buttons lies in how interface components get distributed. A design system like Material Design or Bootstrap doesn’t just define colors and typography: its button components usually come with sample text (“Submit,” “Cancel,” “Learn more”) that many teams leave as-is in production, especially on internal or low-traffic forms.
The same happens with default translation files from internationalization libraries like react-i18next or next-intl: if a project starts from a template with an en.json that includes "cta.accept": "Accept", that value propagates to every fork of the project until someone decides to rewrite it.
| Button pattern | Where it appears | Why it repeats | Recommended alternative |
|---|---|---|---|
| “Accept All” / “Reject All” | Cookie banners (GDPR) | Consent frameworks like the IAB TCF standardize the text | Specify what’s being accepted: “Accept marketing cookies” |
| “Continue with Google” / “Continue with Facebook” | Login forms (OAuth) | SDK brand guidelines dictate the button’s text and style | Keep it, but clarify what data gets shared next to it |
| “Subscribe” / “Register Now” | Newsletters and landing pages | Copied from generic marketing templates | Describe the concrete benefit: “Get the weekly summary” |
| “Send” / “Submit” | Framework forms (Bootstrap, Material) | Default component text that no one overrides | Name the actual action: “Submit order,” “Save changes” |
W3C’s WCAG criterion 2.4.4 (Link Purpose, In Context) asks for exactly the opposite of this pattern: that a button or link’s purpose be understood from its text, without relying on visual context. A generic button repeated dozens of times on the same page breaks that rule for anyone navigating with a screen reader.
<!-- Bad: generic text repeated across thousands of sites -->
<button>Accept</button>
<!-- Better: specific text that says what the user is accepting -->
<button aria-label="Accept analytics and marketing cookies">
Accept All
</button>The difference doesn’t change what the button does, it changes what a screen reader announces and what a user remembers when they come back to that page. The aria-label gives the button an accessible name different from its visible text, without touching the design.
How to Audit Your Own Site’s Buttons
No external tool is needed to detect how many stolen buttons a site has. The browser console (F12 or Cmd+Opt+I) is enough:
// audit-buttons.js: counts how many buttons repeat the exact same text
const botones = document.querySelectorAll('button, a[role="button"], input[type="submit"]');
const conteo = new Map();
botones.forEach((el) => {
const texto = (el.textContent || el.value || '').trim().toLowerCase();
if (!texto) return;
conteo.set(texto, (conteo.get(texto) || 0) + 1);
});
[...conteo.entries()]
.sort((a, b) => b[1] - a[1])
.slice(0, 10)
.forEach(([texto, veces]) => console.log(`"${texto}": ${veces} times`));The script collects all buttons, links with a button role, and submit inputs, counts how many times each exact text repeats, and shows the top 10 in the console. To confirm it’s working, look through the results for the usual suspects: “submit,” “accept,” “continue” tend to top the list on most sites with forms.
💡 Tip: run the script on the checkout page and the registration page separately; those tend to accumulate the most stolen buttons since they come from third-party templates (payment gateways, authentication providers).
Impact and Analysis
The problem isn’t just aesthetic. When several buttons on the same page share the text “Accept,” a user navigating with a screen reader who jumps from button to button (a common quick-navigation technique) can’t tell them apart by name. They have to rely on order or visual context, something the WCAG guidelines themselves advise against.
There’s also a regulatory component. Data protection authorities like France’s CNIL required, starting in 2020, that the “Reject” button carry the same visual weight as “Accept” in cookie banners, precisely because for years the stolen pattern was asymmetric: “Accept All” as a large, colored button, “Reject” as an almost invisible gray link. That regulatory adjustment ended up reinforcing, not reducing, the homogeneity of the text: now almost every CMP offers the same symmetric pair of buttons with the same two words.
flowchart TD
A["Design system (Material, Bootstrap, CMP)"] --> B["Button component with default text"]
B --> C["Product team integrates the component without changing the text"]
C --> D["Thousands of sites end up with the same copy"]
D --> E(("User sees identical 'Accept' on every site"))📌 Note: Zenkov’s own essay serves as evidence for his thesis: it’s almost entirely a list of UI fragments scraped from real sites, unedited, exactly the same gesture it criticizes.
What’s Next
The WCAG 2.2 revision, published in 2023, maintains and reinforces the criteria on link purpose and visible focus, so regulatory pressure toward more specific button text isn’t going to ease up. At the same time, more and more teams are generating interfaces with LLM-based code assistants, which tend to autocomplete the exact same sample text that already dominates the rest of the web (“Submit,” “Accept,” “Learn more”), because those are the ones they saw most often during training. It’s a different mechanism from design systems, but with the same result: more stolen buttons, now generated in seconds instead of copied by hand.
📖 Summary on Telegram: View summary.
Try it yourself: open your own site’s console, paste the button-audit script, and see how many of your buttons are, in fact, stolen buttons.
Frequently Asked Questions
What does “stolen buttons” mean in interface design?
It’s the term designer Anatoly Zenkov uses to describe buttons whose text is copied from another site, framework, or design system without adapting it to the specific context where it’s used.
Why do almost all cookie banners say “Accept All”?
Because most sites use a consent management platform (CMP) based on the IAB Transparency and Consent Framework, which already comes with that text set by default.
Is using the same text on every button an accessibility problem?
Yes, when several buttons on the same page share the exact same text, a screen reader user can’t tell them apart by their accessible name, which goes against WCAG criterion 2.4.4.
What does WCAG say about button text?
Criterion 2.4.4 (Link Purpose, In Context) requires that a button or link’s purpose be understood from its own text, without relying solely on visual context.
How do I audit my own site’s buttons?
With a short JavaScript script in the browser console that counts how many times the exact text of each button, button-role link, or submit input repeats.
Are design systems like Material Design or Bootstrap to blame?
Partly: their components come with default sample text that many teams never replace, but the same pattern repeats in consent frameworks and social login SDKs for different reasons (regulation and brand guidelines).
References
- Stolen Buttons, by Anatoly Zenkov: the original essay that documents and names the phenomenon.
- W3C, Understanding SC 2.4.4: Link Purpose (In Context): the accessibility criterion that requires specific button text.
- GDPR.eu: context on the regulation that triggered cookie consent banners in 2018.
- Material Design 3: documentation for Google’s design system, including its default button components.
- shadcn/ui on GitHub: an example of a modern design system where button text isn’t predefined, but is instead set by each project.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day. @programacion
0 Comments