El botón que dice "Aceptar todo" en el banner de cookies de una tienda online en Buenos Aires es, carácter por carácter, el mismo que aparece en un blog en Berlín o en una fintech en Bogotá. No es plagio en el sentido tradicional: es lo que el diseñador Anatoly Zenkov llamó botones robados en su ensayo Stolen Buttons, la costumbre de copiar y pegar el copy de la interfaz sin que nadie vuelva a diseñarlo.
Zenkov reunió decenas de capturas de banners de consentimiento, formularios de login y popups de suscripción con el mismo texto exacto, muchas veces en idiomas distintos mezclados en la misma página. El resultado es una web donde los botones dicen cada vez menos sobre lo que realmente hace cada acción.
TL;DR
- El concepto de "botones robados" lo acuñó el diseñador Anatoly Zenkov en su ensayo Stolen Buttons.- El patrón más repetido es "Aceptar todo" / "Rechazar todo", estandarizado por marcos de consentimiento como el IAB Transparency and Consent Framework.- Los botones "Continuar con Google" y "Continuar con Facebook" replican el texto exacto que imponen las guías de marca de cada SDK de OAuth.- El criterio 2.4.4 de WCAG (Link Purpose) del W3C exige que el texto de un botón describa la acción, no un genérico repetido.- Design systems como Material Design y Bootstrap distribuyen componentes con texto por defecto que los equipos rara vez sobrescriben.- Auditar los botones de un sitio propio se puede hacer con un script corto de JavaScript en la consola del navegador, sin instalar nada.
Qué pasó
El artículo de Zenkov no es un ensayo convencional: es, en gran parte, una colección cruda de fragmentos de interfaz extraídos de decenas de sitios reales. En la misma lista conviven "Akzeptieren", "Reject All", "Registrieren Sie sich jetzt", "Anmelden", "Save" y "Accept & Close". Esa mezcla de idiomas es la prueba visual del argumento central: los mismos ocho o diez patrones de botón se repiten sin importar el idioma ni el rubro del sitio.
El listado incluye botones de consentimiento de cookies ("Accept All", "Reject All", "Decline"), de autenticación ("Log In", "Sign Up", "Continue with Facebook"), de carritos de compra ("Comprar ahora", "Añadir al carrito") y de suscripción a boletines ("Register Now", "1 month trial"). Ninguno fue pensado específicamente para el sitio donde aparece: todos vienen de una plantilla, un framework de consentimiento o un design system que el equipo de producto integró sin tocar el texto.
Contexto e historia de los botones robados
El fenómeno tiene una fecha de origen bastante clara para el caso más visible: los banners de cookies. El Reglamento General de Protección de Datos (RGPD/GDPR) entró en vigor el 25 de mayo de 2018 y obligó a miles de sitios europeos, y a cualquiera con visitantes europeos, a pedir consentimiento antes de instalar cookies de terceros. La mayoría de esos sitios no diseñó su propio flujo de consentimiento: adoptó una plataforma de gestión de consentimiento (CMP) que ya traía el texto resuelto.
El IAB Europe estandarizó ese flujo con el Transparency and Consent Framework (TCF), que define no solo qué datos se comparten sino, en la práctica, qué botones y qué jerarquía visual usan la mayoría de los CMP del mercado. Por eso "Aceptar todo" y "Rechazar todo" aparecen con el mismo peso visual en sitios que no tienen ninguna otra cosa en común.
El mismo par de botones de consentimiento, traducido pero nunca rediseñado.
Algo parecido pasa con el login social. Cuando un sitio integra el SDK de Google Identity Services o el Login de Facebook, las guías de marca de esas plataformas exigen usar literalmente el texto "Continuar con Google" o "Continue with Facebook", con un logo y un estilo de botón fijos. No es negligencia del equipo de producto: es un requisito contractual del proveedor de OAuth.
Detalles técnicos: por qué el copy se repite
La causa técnica de los botones robados está en cómo se distribuyen los componentes de interfaz. Un design system como Material Design o Bootstrap no solo define colores y tipografías: sus componentes de botón suelen venir con un texto de ejemplo ("Submit", "Cancel", "Learn more") que muchos equipos dejan tal cual en producción, sobre todo en formularios internos o de bajo tráfico.
Lo mismo ocurre con los archivos de traducción por defecto de librerías de internacionalización como react-i18next o next-intl: si un proyecto arranca desde una plantilla con un en.json que trae "cta.accept": "Accept", ese valor se propaga a cada fork del proyecto hasta que alguien decide reescribirlo.
Patrón de botónDónde aparecePor qué se repiteAlternativa recomendada"Aceptar todo" / "Rechazar todo"Banners de cookies (RGPD)Marcos de consentimiento como el IAB TCF estandarizan el textoEspecificar qué se acepta: "Aceptar cookies de marketing""Continuar con Google" / "Continuar con Facebook"Formularios de login (OAuth)Las guías de marca del SDK imponen el texto y el estilo del botónMantenerlo, pero aclarar qué datos se comparten al lado"Suscribirme" / "Registrarme ahora"Newsletters y landing pagesCopiado de plantillas de marketing genéricasDescribir el beneficio concreto: "Recibir el resumen semanal""Enviar" / "Submit"Formularios de frameworks (Bootstrap, Material)Texto por defecto del componente que nadie sobrescribeNombrar la acción real: "Enviar pedido", "Guardar cambios"
El criterio 2.4.4 de WCAG (Link Purpose, In Context) del W3C pide justamente lo contrario a este patrón: que el propósito de un botón o enlace se entienda por su texto, sin depender del contexto visual. Un botón genérico repetido decenas de veces en la misma página rompe esa regla para cualquiera que navegue con lector de pantalla.
Aceptar
Aceptar todo
La diferencia no cambia lo que hace el botón, cambia lo que un lector de pantalla anuncia y lo que un usuario recuerda al volver a esa página. El aria-label le da al botón un nombre accesible distinto del texto visible, sin tocar el diseño.
Cómo auditar los botones de tu propio sitio
No hace falta ninguna herramienta externa para detectar cuántos botones robados tiene un sitio propio. Con la consola del navegador (F12 o Cmd+Opt+I) alcanza:
// audit-buttons.js: cuenta cuantos botones repiten el mismo texto exacto
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} veces`));
El script junta todos los botones, enlaces con rol de botón e inputs de envío, cuenta cuántas veces se repite cada texto exacto y muestra el top 10 en la consola. Para confirmar que está funcionando, buscá en el resultado los sospechosos habituales: "enviar", "aceptar", "continuar" suelen encabezar la lista en la mayoría de los sitios con formularios.
💡 Tip: corré el script en la página de checkout y en la de registro por separado; son las que más botones robados suelen acumular por venir de plantillas de terceros (pasarelas de pago, proveedores de autenticación).
Impacto y análisis
El problema no es solo estético. Cuando varios botones de una misma página comparten el texto "Aceptar", un usuario que navega con lector de pantalla y salta de botón en botón (una técnica común de navegación rápida) no puede distinguirlos por el nombre. Tiene que depender del orden o del contexto visual, algo que la propia guía WCAG desaconseja.
Un componente con texto por defecto se multiplica en cada producto que lo reutiliza.
Hay además un componente regulatorio. Autoridades de protección de datos como la CNIL francesa exigieron desde 2020 que el botón "Rechazar" tenga el mismo peso visual que "Aceptar" en los banners de cookies, precisamente porque durante años el patrón robado fue asimétrico: "Aceptar todo" en un botón grande y de color, "Rechazar" como un link gris casi invisible. Ese ajuste normativo terminó reforzando, no reduciendo, la homogeneidad del texto: ahora casi todos los CMP ofrecen el mismo par de botones simétricos con las mismas dos palabras.
flowchart TD
A["Design system (Material, Bootstrap, CMP)"] --> B["Componente Button con texto por defecto"]
B --> C["Equipo de producto integra el componente sin cambiar el texto"]
C --> D["Miles de sitios terminan con el mismo copy"]
D --> E(("Usuario ve 'Aceptar' identico en cada sitio"))
📌 Nota: el propio ensayo de Zenkov funciona como evidencia de su tesis: es casi enteramente una lista de fragmentos de UI scrapeados de sitios reales, sin reescribir, exactamente el mismo gesto que critica.
Qué sigue
La revisión de WCAG 2.2, publicada en 2023, mantiene y refuerza los criterios sobre propósito del enlace y foco visible, así que la presión normativa hacia un texto de botón más específico no va a bajar. Al mismo tiempo, cada vez más equipos generan interfaces con asistentes de código basados en LLMs, que tienden a autocompletar exactamente los mismos textos de ejemplo que ya dominan el resto de la web ("Submit", "Aceptar", "Learn more"), porque son los que más veces vieron en su entrenamiento. Es un mecanismo distinto al de los design systems, pero con el mismo resultado: más botones robados, generados ahora en segundos en lugar de copiados a mano.
📖 Resumen en Telegram: Ver resumen.
Probalo vos: abrí la consola de tu propio sitio, pegá el script de auditoría de botones y mirá cuántos de los tuyos son, en realidad, botones robados.
Preguntas frecuentes
¿Qué significa "botones robados" en diseño de interfaces?
Es el término que usa el diseñador Anatoly Zenkov para describir botones cuyo texto se copia de otro sitio, framework o design system sin adaptarlo al contexto específico donde se usa.
¿Por qué casi todos los banners de cookies dicen "Aceptar todo"?
Porque la mayoría de los sitios usa una plataforma de gestión de consentimiento (CMP) basada en el IAB Transparency and Consent Framework, que ya trae ese texto resuelto por defecto.
¿Usar el mismo texto en todos los botones es un problema de accesibilidad?
Sí, cuando varios botones de la misma página comparten texto exacto, un usuario de lector de pantalla no puede diferenciarlos por su nombre accesible, lo que va en contra del criterio 2.4.4 de WCAG.
¿Qué dice WCAG sobre el texto de los botones?
El criterio 2.4.4 (Link Purpose, In Context) exige que el propósito de un botón o enlace pueda entenderse a partir de su propio texto, sin depender solo del contexto visual.
¿Cómo audito los botones de mi propio sitio?
Con un script corto de JavaScript en la consola del navegador que cuenta cuántas veces se repite el texto exacto de cada botón, enlace con rol de botón o input de envío.
¿Los design systems como Material Design o Bootstrap tienen la culpa?
En parte: sus componentes traen texto de ejemplo por defecto que muchos equipos nunca reemplazan, pero el mismo patrón se repite en frameworks de consentimiento y SDKs de login social por motivos distintos (regulación y guías de marca).
Referencias
- Stolen Buttons, de Anatoly Zenkov: el ensayo original que documenta y nombra el fenómeno.- W3C, Understanding SC 2.4.4: Link Purpose (In Context): el criterio de accesibilidad que exige texto de botón específico.- GDPR.eu: contexto sobre el reglamento que disparó los banners de consentimiento de cookies en 2018.- Material Design 3: documentación del design system de Google, con los componentes de botón por defecto.- shadcn/ui en GitHub: ejemplo de design system moderno donde el texto del botón no viene predefinido, sino que lo define cada proyecto.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)