Cómo animar un menú móvil con CSS

Posted on by marta

Los menús de navegación para dispositivos móviles se han convertido en un componente imprescindible en la mayoría de los sitios web. Cuando el espacio disponible en pantalla es reducido, la navegación principal suele ocultarse detrás de un botón reconocible, generalmente representado mediante tres líneas horizontales. Al pulsarlo, el menú aparece con una transición que ayuda al usuario a comprender qué está ocurriendo en la interfaz.

Sin embargo, añadir movimiento a un menú no consiste únicamente en aplicar una propiedad transition. Una animación mal planteada puede generar saltos visuales, problemas de rendimiento o dificultades de accesibilidad. Por el contrario, un menú móvil CSS animado correctamente implementado puede mejorar la orientación, reforzar la jerarquía visual y hacer que la navegación resulte más natural.

En esta guía veremos cómo animar un menú móvil con CSS, qué estructura HTML conviene utilizar, cómo controlar su apertura, qué propiedades ofrecen mejor rendimiento y cómo respetar las preferencias de movimiento de cada persona.

¿Qué es un menú móvil animado?

Un menú móvil animado es un sistema de navegación diseñado para pantallas pequeñas que permanece oculto hasta que el usuario activa un botón. Al abrirse o cerrarse, el panel cambia de estado mediante una transición o una animación.

El patrón más habitual es el denominado menú hamburguesa CSS, aunque también pueden utilizarse otros iconos, como una flecha, varios puntos o una etiqueta de texto que indique claramente “Menú”.

La animación puede aplicarse de diferentes maneras:

  • Desplazando el panel desde uno de los laterales.
  • Mostrándolo desde la parte superior.
  • Aplicando una aparición gradual.
  • Escalando el contenido desde un punto concreto.
  • Ocupando toda la pantalla con una capa de navegación.
  • Animando cada enlace con un pequeño retraso.

El objetivo no debería ser llamar la atención mediante efectos complejos. La animación tiene que explicar el cambio de estado, no dificultarlo.

Cuando el menú se desplaza desde el lateral derecho, por ejemplo, el usuario percibe que existe un panel fuera del área visible. Cuando se desvanece, entiende que el elemento estaba oculto y acaba de aparecer. El movimiento aporta contexto espacial a la interacción.

Estructura básica de un menú hamburguesa accesible

Antes de comenzar con la animación, necesitamos una estructura HTML clara y semántica.

Aunque es posible abrir y cerrar un menú utilizando exclusivamente CSS mediante un checkbox, en un proyecto real suele ser preferible emplear un botón y una pequeña cantidad de JavaScript. Esto facilita la gestión de atributos de accesibilidad como aria-expanded.

<header class="site-header">
  <a class="site-logo" href="/">
    Marta González
  </a>

  <button
    class="menu-toggle"
    type="button"
    aria-expanded="false"
    aria-controls="mobile-menu"
    aria-label="Abrir menú"
  >
    <span class="menu-toggle__line"></span>
    <span class="menu-toggle__line"></span>
    <span class="menu-toggle__line"></span>
  </button>

  <nav
    class="mobile-menu"
    id="mobile-menu"
    aria-label="Navegación principal"
  >
    <ul class="mobile-menu__list">
      <li><a href="/">Inicio</a></li>
      <li><a href="/servicios/">Servicios</a></li>
      <li><a href="/proyectos/">Proyectos</a></li>
      <li><a href="/blog/">Blog</a></li>
      <li><a href="/contacto/">Contacto</a></li>
    </ul>
  </nav>
</header>

El botón utiliza aria-controls para indicar qué elemento controla. El atributo aria-expanded comunica si el menú está abierto o cerrado.

Estos detalles no modifican la apariencia, pero sí ayudan a quienes navegan mediante lectores de pantalla u otras tecnologías de asistencia.

¿Por qué conviene utilizar un botón?

Un error habitual consiste en crear el activador mediante un <div> o un <span>. Aunque estos elementos pueden recibir eventos de clic, no ofrecen de forma predeterminada el comportamiento de un botón.

Un elemento <button>:

  • Puede recibir el foco mediante teclado.
  • Se activa con las teclas adecuadas.
  • Tiene una semántica reconocible.
  • Permite utilizar atributos aria.
  • No requiere recrear manualmente comportamientos nativos.

Siempre que un elemento ejecute una acción, el botón suele ser la opción correcta.

Cómo crear la apariencia inicial del menú

Empecemos definiendo algunas variables y los estilos generales del encabezado.

:root {
  --header-height: 4.5rem;
  --menu-background: #ffffff;
  --menu-text: #020101;
  --menu-accent: #cc2b5e;
  --menu-duration: 350ms;
  --menu-easing: cubic-bezier(0.22, 1, 0.36, 1);
}

*,
*::before,
*::after {
  box-sizing: border-box;
}

body {
  margin: 0;
  color: var(--menu-text);
  font-family: system-ui, sans-serif;
}

.site-header {
  position: relative;
  z-index: 20;
  display: flex;
  min-height: var(--header-height);
  align-items: center;
  justify-content: space-between;
  padding-inline: 1.25rem;
  background: #ffffff;
}

.site-logo {
  position: relative;
  z-index: 30;
  color: inherit;
  font-weight: 700;
  text-decoration: none;
}

El z-index del encabezado será importante cuando coloquemos el menú en una capa independiente.

Estilos del botón hamburguesa

El botón tendrá tres líneas que después transformaremos en una cruz.

.menu-toggle {
  position: relative;
  z-index: 30;
  display: grid;
  width: 3rem;
  height: 3rem;
  padding: 0.65rem;
  border: 0;
  background: transparent;
  cursor: pointer;
}

.menu-toggle__line {
  display: block;
  width: 100%;
  height: 2px;
  margin: auto;
  border-radius: 999px;
  background: currentColor;
  transform-origin: center;
  transition:
    transform var(--menu-duration) var(--menu-easing),
    opacity 200ms ease;
}

.menu-toggle:focus-visible {
  outline: 3px solid var(--menu-accent);
  outline-offset: 3px;
}

El estilo :focus-visible permite mostrar un indicador claro cuando el control recibe el foco mediante teclado.

No conviene eliminar el contorno con outline: none sin proporcionar una alternativa. El foco visible es esencial para saber qué elemento está activo.

Cómo animar un menú móvil con CSS mediante transform

Una de las soluciones más eficaces consiste en colocar el menú fuera de la pantalla y desplazarlo cuando se activa.

.mobile-menu {
  position: fixed;
  inset: 0 0 0 auto;
  z-index: 10;
  display: grid;
  width: min(85vw, 25rem);
  min-height: 100dvh;
  padding:
    calc(var(--header-height) + 2rem)
    2rem
    2rem;
  background: var(--menu-background);
  box-shadow: -1rem 0 3rem rgb(0 0 0 / 15%);
  transform: translateX(100%);
  visibility: hidden;
  transition:
    transform var(--menu-duration) var(--menu-easing),
    visibility 0s linear var(--menu-duration);
}

.mobile-menu.is-open {
  transform: translateX(0);
  visibility: visible;
  transition:
    transform var(--menu-duration) var(--menu-easing),
    visibility 0s linear 0s;
}

El panel empieza con translateX(100%), por lo que queda desplazado hacia la derecha. Al añadir la clase .is-open, vuelve a su posición original.

La propiedad visibility evita que los enlaces ocultos puedan recibir el foco. Su transición se retrasa durante el cierre para que el panel no desaparezca antes de completar el movimiento.

¿Por qué utilizar transform en lugar de left o right?

También podríamos animar la propiedad right:

.mobile-menu {
  right: -100%;
}

.mobile-menu.is-open {
  right: 0;
}

Visualmente podría ofrecer un resultado parecido, pero animar propiedades relacionadas con la posición y la geometría puede obligar al navegador a recalcular la distribución de la página.

En cambio, transform suele ser una opción más adecuada para el movimiento. Por este motivo, al plantear una mobile menu animation CSS, normalmente conviene priorizar:

  • transform
  • opacity

Estas propiedades permiten crear animaciones fluidas sin modificar continuamente las dimensiones o la posición calculada del documento.

Controlar la apertura del menú con JavaScript

CSS se ocupará de la animación, mientras que JavaScript cambiará el estado del componente.

const menuButton = document.querySelector(".menu-toggle");
const mobileMenu = document.querySelector(".mobile-menu");

function setMenuState(isOpen) {
  mobileMenu.classList.toggle("is-open", isOpen);
  menuButton.classList.toggle("is-active", isOpen);

  menuButton.setAttribute("aria-expanded", String(isOpen));
  menuButton.setAttribute(
    "aria-label",
    isOpen ? "Cerrar menú" : "Abrir menú"
  );

  document.body.classList.toggle("menu-open", isOpen);
}

menuButton.addEventListener("click", () => {
  const isOpen =
    menuButton.getAttribute("aria-expanded") === "true";

  setMenuState(!isOpen);
});

La función centraliza todos los cambios relacionados con el estado:

  • Añade o elimina la clase del panel.
  • Actualiza el botón.
  • Modifica aria-expanded.
  • Cambia la etiqueta accesible.
  • Añade una clase al body.

Esta última clase permite impedir que la página continúe desplazándose mientras el menú ocupa la pantalla.

body.menu-open {
  overflow: hidden;
}

Centralizar el comportamiento evita inconsistencias. Si en el futuro añadimos nuevas formas de cerrar el menú, todas podrán llamar a la misma función.

Cómo transformar el icono hamburguesa en una cruz

Las líneas del botón también pueden animarse para indicar que el menú se encuentra abierto.

.menu-toggle.is-active .menu-toggle__line:nth-child(1) {
  transform: translateY(0.56rem) rotate(45deg);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(2) {
  opacity: 0;
  transform: scaleX(0);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(3) {
  transform: translateY(-0.56rem) rotate(-45deg);
}

La primera y la tercera línea se desplazan hacia el centro y rotan. La línea central desaparece mediante opacity y scaleX.

El resultado es una transición reconocible entre el icono de menú y el icono de cierre.

Ajustar la transformación sin valores frágiles

El desplazamiento de las líneas depende del tamaño del botón, del espacio disponible y de la distribución interna. Por ello, no conviene copiar valores de otro proyecto sin revisarlos.

Una alternativa más controlable consiste en posicionar las líneas de forma absoluta:

.menu-toggle {
  position: relative;
}

.menu-toggle__line {
  position: absolute;
  left: 25%;
  width: 50%;
}

.menu-toggle__line:nth-child(1) {
  top: 32%;
}

.menu-toggle__line:nth-child(2) {
  top: 50%;
  transform: translateY(-50%);
}

.menu-toggle__line:nth-child(3) {
  bottom: 32%;
}

.menu-toggle.is-active .menu-toggle__line:nth-child(1) {
  top: 50%;
  transform: translateY(-50%) rotate(45deg);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(2) {
  opacity: 0;
  transform: translateY(-50%) scaleX(0);
}

.menu-toggle.is-active .menu-toggle__line:nth-child(3) {
  bottom: 50%;
  transform: translateY(50%) rotate(-45deg);
}

Esta solución ofrece un mayor control sobre el punto en el que las líneas se cruzan.

Animar los enlaces del menú de forma escalonada

Además del panel, podemos animar cada enlace con un pequeño retraso. Este recurso se conoce habitualmente como animación escalonada o staggered animation.

.mobile-menu__list {
  display: grid;
  gap: 0.75rem;
  margin: 0;
  padding: 0;
  list-style: none;
}

.mobile-menu__list li {
  opacity: 0;
  transform: translateX(1.25rem);
  transition:
    transform 300ms var(--menu-easing),
    opacity 300ms ease;
}

.mobile-menu.is-open .mobile-menu__list li {
  opacity: 1;
  transform: translateX(0);
}

Después podemos aplicar diferentes retrasos:

.mobile-menu.is-open .mobile-menu__list li:nth-child(1) {
  transition-delay: 80ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(2) {
  transition-delay: 120ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(3) {
  transition-delay: 160ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(4) {
  transition-delay: 200ms;
}

.mobile-menu.is-open .mobile-menu__list li:nth-child(5) {
  transition-delay: 240ms;
}

El desfase debe ser breve. Si cada elemento tarda demasiado en aparecer, el usuario tendrá que esperar para encontrar el enlace que necesita.

Una animación escalonada funciona mejor cuando:

  • Hay pocos elementos.
  • Los retrasos son reducidos.
  • El movimiento conserva una misma dirección.
  • El contenido continúa siendo usable con rapidez.

Utilizar una variable CSS para controlar el retraso

Podemos evitar varios selectores nth-child utilizando una variable personalizada:

<li style="--item-index: 0"><a href="/">Inicio</a></li>
<li style="--item-index: 1"><a href="/servicios/">Servicios</a></li>
<li style="--item-index: 2"><a href="/proyectos/">Proyectos</a></li>
<li style="--item-index: 3"><a href="/blog/">Blog</a></li>
<li style="--item-index: 4"><a href="/contacto/">Contacto</a></li>

.mobile-menu.is-open .mobile-menu__list li {
  transition-delay: calc(70ms + var(--item-index) * 40ms);
}

Así, la duración puede ajustarse desde un único lugar.

Añadir una capa oscura detrás del menú

Cuando el menú aparece como un panel lateral, resulta útil oscurecer el contenido situado detrás. Esta capa dirige la atención y comunica que la página principal se encuentra temporalmente inactiva.

Podemos crearla mediante un pseudoelemento:

.site-header::before {
  content: "";
  position: fixed;
  inset: 0;
  z-index: 5;
  background: rgb(0 0 0 / 45%);
  opacity: 0;
  visibility: hidden;
  transition:
    opacity var(--menu-duration) ease,
    visibility 0s linear var(--menu-duration);
}

.site-header:has(.mobile-menu.is-open)::before {
  opacity: 1;
  visibility: visible;
  transition:
    opacity var(--menu-duration) ease,
    visibility 0s linear 0s;
}

La pseudoclase :has() permite modificar el encabezado cuando contiene un menú abierto.

También podemos crear una capa independiente en el HTML. Esta alternativa resulta práctica cuando queremos cerrar el menú al pulsar fuera del panel.

<div class="menu-overlay" aria-hidden="true"></div>

.menu-overlay {
  position: fixed;
  inset: 0;
  z-index: 5;
  background: rgb(0 0 0 / 45%);
  opacity: 0;
  visibility: hidden;
  transition:
    opacity var(--menu-duration) ease,
    visibility 0s linear var(--menu-duration);
}

.menu-overlay.is-visible {
  opacity: 1;
  visibility: visible;
  transition-delay: 0s;
}

Y actualizamos JavaScript:

const menuOverlay = document.querySelector(".menu-overlay");

function setMenuState(isOpen) {
  mobileMenu.classList.toggle("is-open", isOpen);
  menuButton.classList.toggle("is-active", isOpen);
  menuOverlay.classList.toggle("is-visible", isOpen);

  menuButton.setAttribute("aria-expanded", String(isOpen));
  menuButton.setAttribute(
    "aria-label",
    isOpen ? "Cerrar menú" : "Abrir menú"
  );

  document.body.classList.toggle("menu-open", isOpen);
}

menuOverlay.addEventListener("click", () => {
  setMenuState(false);
});

Cerrar el menú con la tecla Escape

Un menú accesible debería poder cerrarse mediante la tecla Escape.

document.addEventListener("keydown", (event) => {
  if (event.key !== "Escape") {
    return;
  }

  const isOpen =
    menuButton.getAttribute("aria-expanded") === "true";

  if (isOpen) {
    setMenuState(false);
    menuButton.focus();
  }
});

Al cerrar el panel, devolvemos el foco al botón que lo abrió. De esta forma, quien navega mediante teclado no pierde su posición en la interfaz.

También puede ser conveniente cerrar el menú después de seleccionar un enlace:

mobileMenu.addEventListener("click", (event) => {
  const clickedLink = event.target.closest("a");

  if (clickedLink) {
    setMenuState(false);
  }
});

Esta medida resulta especialmente útil en páginas de una sola sección, donde los enlaces llevan a distintos puntos del mismo documento.

Animaciones alternativas para un menú móvil

El desplazamiento lateral es una solución frecuente, pero no es la única forma de animar un menú CSS.

Menú desplegable desde la parte superior

Podemos hacer que el menú aparezca debajo del encabezado.

.mobile-menu {
  position: absolute;
  top: 100%;
  right: 0;
  left: 0;
  min-height: auto;
  transform: translateY(-1rem);
  opacity: 0;
  visibility: hidden;
  transition:
    transform 250ms ease,
    opacity 250ms ease,
    visibility 0s linear 250ms;
}

.mobile-menu.is-open {
  transform: translateY(0);
  opacity: 1;
  visibility: visible;
  transition-delay: 0s;
}

Esta variante funciona bien en menús cortos que no necesitan ocupar toda la pantalla.

Menú a pantalla completa

Un menú superpuesto puede ocupar todo el viewport:

.mobile-menu {
  position: fixed;
  inset: 0;
  display: grid;
  place-items: center;
  min-height: 100dvh;
  padding: 5rem 2rem 2rem;
  background: var(--menu-background);
  opacity: 0;
  transform: scale(1.03);
  visibility: hidden;
  transition:
    opacity 300ms ease,
    transform 400ms var(--menu-easing),
    visibility 0s linear 400ms;
}

.mobile-menu.is-open {
  opacity: 1;
  transform: scale(1);
  visibility: visible;
  transition-delay: 0s;
}

El cambio de escala debe ser sutil. Una ampliación excesiva puede resultar agresiva o generar una sensación de movimiento innecesaria.

Aparición mediante clip-path

Otra opción visual consiste en revelar el menú progresivamente con clip-path.

.mobile-menu {
  position: fixed;
  inset: 0;
  clip-path: circle(0 at calc(100% - 2.5rem) 2.5rem);
  visibility: hidden;
  transition:
    clip-path 500ms var(--menu-easing),
    visibility 0s linear 500ms;
}

.mobile-menu.is-open {
  clip-path: circle(150% at calc(100% - 2.5rem) 2.5rem);
  visibility: visible;
  transition-delay: 0s;
}

Este efecto puede resultar atractivo, pero debería comprobarse en los navegadores y dispositivos incluidos en los requisitos del proyecto.

La solución más llamativa no siempre es la más adecuada. Para la mayoría de las interfaces, una transición sencilla con transform y opacity será más fácil de mantener.

Cómo respetar prefers-reduced-motion

Algunas personas reducen las animaciones en el sistema operativo porque el movimiento puede provocar molestias, mareos o dificultades de concentración.

La media query prefers-reduced-motion permite adaptar la experiencia.

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    scroll-behavior: auto !important;
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    transition-delay: 0ms !important;
  }
}

También podemos aplicar una versión más específica:

@media (prefers-reduced-motion: reduce) {
  .mobile-menu,
  .mobile-menu__list li,
  .menu-toggle__line,
  .menu-overlay {
    transition: none;
  }
}

La segunda opción evita modificar todas las animaciones del proyecto y se limita al componente.

Respetar esta preferencia no significa eliminar funcionalidad. El menú debe continuar abriéndose y cerrándose, pero sin una transición prolongada.

Adaptar el menú a escritorio

Un menú móvil no debería continuar oculto detrás de un botón cuando existe espacio suficiente para mostrar la navegación completa.

@media (min-width: 48rem) {
  .menu-toggle,
  .menu-overlay {
    display: none;
  }

  .mobile-menu {
    position: static;
    display: block;
    width: auto;
    min-height: auto;
    padding: 0;
    background: transparent;
    box-shadow: none;
    transform: none;
    visibility: visible;
  }

  .mobile-menu__list {
    display: flex;
    align-items: center;
    gap: 1.5rem;
  }

  .mobile-menu__list li {
    opacity: 1;
    transform: none;
    transition: none;
  }

  body.menu-open {
    overflow: auto;
  }
}

El punto de ruptura no debería elegirse únicamente por un dispositivo concreto. Conviene observar el momento en el que los enlaces dejan de caber cómodamente en una línea.

Un menú puede necesitar transformarse en móvil a 768 píxeles, 900 píxeles o cualquier otra anchura, dependiendo de:

  • La cantidad de enlaces.
  • La longitud de las etiquetas.
  • El tamaño del logotipo.
  • El espacio entre elementos.
  • El idioma del sitio.
  • El diseño general del encabezado.

Errores frecuentes al animar un menú móvil

Animar display: none

La propiedad display no puede interpolarse como opacity o transform.

Este código no producirá una transición gradual:

.mobile-menu {
  display: none;
  opacity: 0;
}

.mobile-menu.is-open {
  display: block;
  opacity: 1;
}

Cuando el elemento pasa de display: none a display: block, aparece directamente. Después puede aplicarse la opacidad, pero el proceso no siempre ofrece el resultado esperado.

Para controlar la interacción y la visibilidad durante una transición, podemos combinar:

  • opacity
  • transform
  • visibility
  • pointer-events

Ocultar el menú solo con opacity

Un elemento con opacity: 0 continúa ocupando espacio y puede seguir recibiendo clics o foco.

Por ello, este código es insuficiente:

.mobile-menu {
  opacity: 0;
}

Podemos reforzarlo así:

.mobile-menu {
  opacity: 0;
  visibility: hidden;
  pointer-events: none;
}

.mobile-menu.is-open {
  opacity: 1;
  visibility: visible;
  pointer-events: auto;
}

Utilizar duraciones demasiado largas

Un menú es una herramienta funcional. El usuario quiere acceder rápidamente a otra sección.

Las transiciones de entre aproximadamente 200 y 400 milisegundos suelen ofrecer una sensación fluida sin introducir una espera evidente. No obstante, la duración adecuada dependerá del tamaño del panel y de la distancia recorrida.

Un panel que atraviesa toda la pantalla puede necesitar algo más de tiempo que un pequeño cambio de opacidad, pero rara vez requiere una animación de un segundo completo.

Sobrecargar el componente con efectos

Mover el panel, escalarlo, rotarlo, difuminarlo y animar simultáneamente todos sus enlaces puede dificultar la lectura.

Una buena regla práctica consiste en elegir:

  1. Una animación principal para el contenedor.
  2. Una transformación clara para el botón.
  3. Una animación secundaria opcional para los enlaces.

Más efectos no implican una mejor experiencia.

No comprobar la navegación mediante teclado

El menú puede parecer correcto con el ratón y presentar problemas al utilizar la tecla Tab.

Antes de darlo por terminado, conviene comprobar que:

  • El botón recibe el foco.
  • El estado del foco es visible.
  • Los enlaces ocultos no pueden enfocarse.
  • El menú puede cerrarse con Escape.
  • El foco vuelve al botón al cerrar.
  • El orden de navegación es lógico.

Prestar atención al control del foco

En un menú que ocupa toda la pantalla, puede ser recomendable mantener temporalmente el foco dentro del panel mientras permanece abierto. Esto se conoce como focus trapping.

No todos los menús desplegables necesitan comportarse como un diálogo modal. Sin embargo, cuando la navegación bloquea completamente el resto de la interfaz, conviene estudiar si el foco debería quedar limitado a sus controles.

Consejos para conseguir una animación más profesional

Mantén una dirección coherente

Si el panel entra desde la derecha, los enlaces pueden aparecer desplazándose ligeramente desde esa misma dirección. Esta coherencia ayuda a que el movimiento resulte predecible.

Utiliza una curva de aceleración adecuada

La función ease puede ser suficiente, pero una curva personalizada permite controlar mejor la sensación de movimiento.

transition-timing-function: cubic-bezier(0.22, 1, 0.36, 1);

Esta curva genera una entrada rápida que se suaviza al llegar al destino. El menú se percibe ágil sin detenerse de forma brusca.

Evita utilizar will-change permanentemente

La propiedad will-change puede avisar al navegador de que un elemento cambiará próximamente:

.mobile-menu {
  will-change: transform;
}

Sin embargo, no debería aplicarse indiscriminadamente a muchos componentes. Mantener capas optimizadas de forma permanente puede aumentar el consumo de recursos.

En un menú pequeño quizá no sea necesaria. Conviene utilizarla únicamente cuando las pruebas de rendimiento muestren una mejora real.

Prueba en dispositivos reales

Las herramientas del navegador permiten simular diferentes anchuras, pero no reproducen por completo:

  • El rendimiento de un teléfono de gama media o baja.
  • La interacción táctil.
  • La barra dinámica del navegador.
  • Los cambios de orientación.
  • El comportamiento del teclado virtual.
  • Las áreas seguras de algunos dispositivos.

Para la altura del panel, 100dvh puede adaptarse mejor a los cambios de la interfaz del navegador que el tradicional 100vh.

Lista de comprobación antes de publicar

Antes de dar por finalizado el menú hamburguesa CSS, revisa los siguientes puntos:

  • El botón es un elemento <button>.
  • Incluye aria-controls y aria-expanded.
  • El texto accesible cambia entre abrir y cerrar.
  • El menú oculto no puede recibir el foco.
  • La animación utiliza preferentemente transform y opacity.
  • El contenido no se desplaza accidentalmente al abrir el panel.
  • Existe una forma clara de cerrar el menú.
  • La tecla Escape funciona.
  • El foco es visible.
  • Se respeta prefers-reduced-motion.
  • El menú se adapta correctamente a escritorio.
  • Los enlaces tienen un área táctil suficiente.
  • La duración de la transición no retrasa la navegación.
  • El comportamiento se ha probado con teclado y pantalla táctil.

Esta revisión permite detectar problemas que pueden pasar desapercibidos cuando solo se evalúa la apariencia visual.

Preguntas frecuentes sobre cómo animar un menú móvil con CSS

¿Es posible crear un menú móvil animado solo con CSS?

Sí. Puede utilizarse un checkbox oculto junto con un <label> y selectores como :checked para modificar el estado del menú.

No obstante, esta solución puede complicar la semántica y la actualización de atributos accesibles. En proyectos reales suele resultar más mantenible utilizar CSS para la presentación y una pequeña cantidad de JavaScript para gestionar el estado.

¿Qué propiedades CSS conviene utilizar para animar un menú?

Las propiedades más recomendables son transform y opacity. Permiten desplazar, escalar o desvanecer el menú sin depender continuamente de cambios en su geometría.

Propiedades como width, height, left, right o margin pueden utilizarse, pero suelen requerir más trabajo del navegador durante la animación. Siempre conviene comprobar el resultado con las herramientas de rendimiento.

¿Cuánto debería durar la animación de un menú hamburguesa?

La duración debe ser suficiente para que el cambio de estado se entienda, pero no tan larga como para retrasar el acceso a los enlaces.

Como referencia inicial, pueden probarse valores entre 200 y 400 milisegundos. Los efectos secundarios, como la aparición escalonada de los enlaces, deberían utilizar retrasos pequeños para evitar que la navegación se sienta lenta.

El movimiento debe acompañar a la navegación, no competir con ella

Aprender cómo animar un menú móvil con CSS implica algo más que elegir un efecto llamativo. El componente debe ser comprensible, rápido, accesible y fácil de mantener.

Una animación lateral mediante transform, acompañada de una capa de fondo y una transformación sencilla del botón, suele ser suficiente para crear una experiencia clara. A partir de esa base pueden añadirse detalles como la entrada escalonada de los enlaces, siempre que no retrasen la interacción.

También es importante recordar que el menú es una de las principales vías de acceso al contenido. Si su apertura resulta confusa, si los enlaces ocultos reciben el foco o si el movimiento genera molestias, la animación deja de cumplir su función.

La mejor animación no es necesariamente la más compleja. Es aquella que hace visible el cambio de estado sin obligar al usuario a pensar en el propio efecto. Cuando el movimiento acompaña de forma natural a la navegación, el diseño se percibe más cuidado y la interfaz resulta más fácil de utilizar.

Qué son los overlays de accesibilidad y por qué son un problema

Posted on by marta

La accesibilidad web se ha convertido en un tema cada vez más importante dentro del diseño, el desarrollo frontend, la experiencia de usuario y la estrategia digital. Ya no hablamos solo de “hacer una web bonita” o de que una página cargue rápido. También hablamos de que cualquier persona pueda navegar, leer, interactuar, comprar, registrarse, enviar un formulario o consumir contenido sin encontrarse con barreras innecesarias.

En ese contexto han aparecido muchas soluciones que prometen mejorar la accesibilidad de una web de forma rápida. Entre ellas están los llamados overlays de accesibilidad, también conocidos como widgets de accesibilidad, plugins de accesibilidad o herramientas automáticas de accesibilidad.

A primera vista, pueden parecer una buena idea. Instalas un script, aparece un botón flotante en la web y, al hacer clic, se despliega un panel con opciones como aumentar el tamaño del texto, cambiar el contraste, resaltar enlaces o activar una supuesta mejora para lectores de pantalla. Suena fácil, barato y práctico. Pero la realidad es bastante más compleja.

El problema de los overlays no es solo que sean limitados. El problema es que pueden crear una falsa sensación de accesibilidad. Es decir, pueden hacer creer que una web ya es accesible cuando, en realidad, muchos errores siguen estando en el código, en la estructura, en los formularios, en la navegación, en los contenidos o en los componentes interactivos.

En este artículo vamos a ver qué son los overlays de accesibilidad, por qué se han popularizado, cuáles son sus principales problemas y qué alternativas existen para trabajar una accesibilidad web real, sostenible y útil para las personas.

Qué son los overlays de accesibilidad

Los overlays de accesibilidad son herramientas externas que se añaden a una página web, normalmente mediante un fragmento de código JavaScript. Su función es superponer una capa de opciones sobre la web existente para intentar modificar ciertos aspectos de la experiencia de usuario.

Por eso se llaman overlays: porque actúan como una capa por encima del sitio web. No reconstruyen la web desde su base, sino que intentan intervenir sobre lo que ya existe.

En muchos casos, estos overlays aparecen como un botón flotante, normalmente situado en una esquina de la pantalla. Al pulsarlo, se abre un panel con distintas opciones de personalización. Algunas de las más habituales son:

  • Aumentar o reducir el tamaño del texto.
  • Cambiar el contraste de color.
  • Activar un modo de alto contraste.
  • Convertir la página a escala de grises.
  • Resaltar enlaces.
  • Cambiar el espaciado del texto.
  • Detener animaciones.
  • Mostrar una guía de lectura.
  • Modificar el cursor.
  • Activar una supuesta navegación mejorada por teclado.
  • Añadir ajustes relacionados con lectores de pantalla.

Algunas herramientas también prometen corregir automáticamente errores de accesibilidad, como textos alternativos ausentes, problemas de ARIA, etiquetas de formularios o estructura semántica. Y es justo aquí donde empiezan las dudas más importantes.

La diferencia entre ayudar y corregir

Una cosa es ofrecer opciones adicionales que puedan ayudar a algunas personas en momentos concretos. Otra muy distinta es afirmar que una herramienta automática puede convertir cualquier web en accesible sin tocar su código ni revisar su diseño.

La accesibilidad web no se basa solo en cambiar colores o agrandar textos. También depende de cómo está construida la página: si usa HTML semántico, si los formularios tienen etiquetas correctas, si los botones son realmente botones, si se puede navegar con teclado, si el foco es visible, si los mensajes de error se entienden y si las tecnologías de asistencia pueden interpretar bien la interfaz.

Un overlay puede actuar sobre algunos elementos visuales, pero no puede garantizar por sí solo que toda la experiencia sea accesible.

Por qué se han popularizado los overlays de accesibilidad

Los overlays se han popularizado porque responden a una necesidad real: muchas webs tienen problemas de accesibilidad y muchas empresas no saben cómo solucionarlos.

La accesibilidad puede parecer un tema técnico, amplio y difícil de abordar. Requiere conocimientos de diseño, desarrollo, contenidos, experiencia de usuario y normativa. Además, corregir una web que no fue pensada con accesibilidad desde el inicio puede implicar tiempo, presupuesto y cambios estructurales.

Frente a eso, los overlays prometen una solución rápida. Y esa promesa resulta muy atractiva.

El atractivo de una solución inmediata

Para una empresa que quiere mejorar su web sin rehacerla, un widget de accesibilidad puede parecer una salida sencilla. Se instala rápido, se ve visualmente en la interfaz y da la sensación de que se ha tomado una medida concreta.

Desde fuera, el botón flotante transmite una idea clara: “esta web se preocupa por la accesibilidad”. Pero que algo parezca accesible no significa que realmente lo sea.

El riesgo está en confundir una señal visual con una solución técnica y funcional. La accesibilidad no se mide por la presencia de un botón, sino por la capacidad real de la web para ser utilizada por personas con distintas capacidades, dispositivos, contextos y tecnologías de asistencia.

El miedo al incumplimiento

Otro motivo por el que se instalan overlays es el miedo a incumplir normativas o recibir reclamaciones. Cada vez hay más conciencia sobre la importancia de la accesibilidad digital, y también más presión para que webs, aplicaciones y servicios digitales sean inclusivos.

En ese escenario, algunas organizaciones buscan una forma rápida de demostrar que están haciendo algo. El problema es que instalar un overlay no equivale a cumplir con la accesibilidad web.

Las WCAG, que son una de las referencias más importantes en accesibilidad digital, se centran en que el contenido sea perceptible, operable, comprensible y robusto. Estos principios no se resuelven únicamente con un panel flotante. Requieren decisiones de diseño, código y contenido bien planteadas.

La accesibilidad entendida como parche

Los overlays también se han popularizado porque encajan con una forma muy extendida de trabajar: dejar la accesibilidad para el final.

Primero se diseña la web. Después se desarrolla. Luego se publica. Y, si alguien detecta un problema, entonces se busca una solución rápida. Pero la accesibilidad no debería funcionar como un parche de última hora.

Cuando se piensa al final, todo cuesta más. Hay que corregir componentes, revisar plantillas, modificar flujos, rehacer formularios, ajustar colores y cambiar decisiones que ya estaban aprobadas. En cambio, cuando la accesibilidad se integra desde el principio, el resultado suele ser más sólido, coherente y fácil de mantener.

Por qué los overlays de accesibilidad son un problema

Los overlays de accesibilidad pueden parecer una ayuda, pero confiar en ellos como solución principal puede generar problemas importantes. Algunos son técnicos, otros legales, otros de experiencia de usuario y otros de percepción.

No corrigen la raíz del problema

El primer problema es que un overlay actúa sobre la superficie. Puede modificar ciertos aspectos visuales o añadir comportamientos dinámicos, pero no cambia necesariamente la base de la web.

Si una página tiene encabezados desordenados, enlaces poco descriptivos, botones mal construidos, formularios sin etiquetas, imágenes informativas sin texto alternativo o componentes inaccesibles, la solución real está en el código y en el diseño del sistema.

Un overlay puede intentar corregir algunas cosas de forma automática, pero esas correcciones no siempre son fiables. Además, pueden depender de cómo cargue la página, de cómo esté construido el DOM, de si hay contenido dinámico o de si otros scripts interfieren en la experiencia.

Ejemplo sencillo con un formulario

Imagina un formulario de contacto donde el campo de email no tiene una etiqueta asociada correctamente. Una persona que usa lector de pantalla puede llegar al campo y no saber qué información debe introducir.

Un overlay podría intentar interpretar el contexto y añadir una etiqueta automática. Pero esa interpretación puede fallar si hay varios campos parecidos, si el formulario se carga dinámicamente o si el diseño no ofrece suficiente información semántica.

La solución más robusta es mucho más sencilla: construir el formulario correctamente desde el principio, con su etiqueta asociada, instrucciones claras, mensajes de error comprensibles y soporte para navegación por teclado.

Pueden interferir con tecnologías de asistencia

Muchas personas ya utilizan sus propias herramientas de accesibilidad: lectores de pantalla, magnificadores, navegación por teclado, comandos de voz, ajustes del sistema operativo, preferencias del navegador o extensiones personalizadas.

Un overlay puede interferir con estas tecnologías. Puede cambiar el orden de lectura, modificar roles, alterar el foco, añadir controles innecesarios o generar comportamientos inesperados.

Esto es especialmente problemático porque una persona que usa tecnología de asistencia no necesita que la web le imponga otra capa adicional. Necesita que la web esté bien construida para funcionar con las herramientas que ya utiliza.

Añaden más complejidad a la interfaz

Un botón flotante puede parecer inofensivo, pero también puede añadir ruido visual. Puede tapar contenido, competir con otros elementos fijos, dificultar la lectura o aumentar la carga cognitiva.

Para algunas personas, tener más opciones no significa tener una experiencia más accesible. A veces significa tener que tomar más decisiones antes de poder hacer algo tan básico como leer una página o completar una tarea.

La accesibilidad real debería estar integrada en la experiencia por defecto. La persona usuaria no debería tener que abrir un panel, revisar múltiples opciones y configurar la web para poder utilizarla con normalidad.

Pueden generar una falsa sensación de cumplimiento

Uno de los riesgos más delicados de los overlays es que pueden hacer pensar que la accesibilidad ya está resuelta. Esto puede frenar inversiones reales en auditoría, diseño inclusivo, formación del equipo y corrección técnica.

Es decir, el overlay no solo no soluciona todos los problemas, sino que puede retrasar la solución de los problemas reales.

Cuando una organización instala un widget y considera que el trabajo está hecho, la accesibilidad deja de abordarse como una responsabilidad continua. Se convierte en una casilla marcada, aunque la experiencia de muchas personas siga siendo deficiente.

Accesibilidad real frente a accesibilidad cosmética

Para entender mejor el debate sobre los overlays, conviene diferenciar entre accesibilidad real y accesibilidad cosmética.

La accesibilidad cosmética se centra en elementos visibles que comunican una intención: un botón flotante, un panel de opciones, una declaración genérica o una promesa de cumplimiento automático.

La accesibilidad real, en cambio, se nota en la experiencia completa. Está en la forma en la que se estructura el contenido, se navega con teclado, se leen los formularios, se anuncian los errores, se gestionan los cambios dinámicos y se diseñan los componentes.

Una web accesible no debería depender de un botón

Una web accesible debería poder usarse correctamente sin necesidad de activar un modo especial. Eso no significa que las opciones de personalización sean inútiles. Pueden ser útiles. Pero no deberían compensar errores básicos de diseño o desarrollo.

Si el contraste de color es insuficiente, la solución no debería depender de que alguien active un modo de alto contraste. La solución debería ser definir una paleta con contraste adecuado desde el principio.

Si los enlaces no se distinguen bien, no debería ser necesario activar una opción para resaltarlos. Los enlaces deberían ser identificables por defecto.

Si una animación resulta molesta o dificulta la lectura, no debería esconderse detrás de una opción del overlay. La web debería respetar preferencias como la reducción de movimiento y usar las animaciones con intención.

La accesibilidad no es solo visual

Muchos overlays se centran en ajustes visuales, pero la accesibilidad web es mucho más amplia.

Una persona que navega con teclado necesita un orden de foco lógico. Una persona que usa lector de pantalla necesita nombres accesibles claros. Una persona con dificultades cognitivas necesita instrucciones comprensibles. Una persona con movilidad reducida necesita poder interactuar sin depender del ratón. Una persona con baja visión necesita contraste suficiente y una estructura clara.

Nada de esto se resuelve de forma universal con una capa externa. Se resuelve diseñando y desarrollando con accesibilidad desde la base.

Problemas que un overlay no puede solucionar bien

Aunque algunas herramientas prometen corregir automáticamente muchos errores, hay problemas de accesibilidad que requieren criterio humano, revisión contextual y cambios reales en el producto.

Formularios mal estructurados

Los formularios son uno de los puntos más sensibles de una web. Para que sean accesibles, los campos deben tener etiquetas asociadas, instrucciones claras, agrupaciones cuando corresponda, validaciones comprensibles y mensajes de error que puedan ser percibidos por tecnologías de asistencia.

Un overlay puede intentar añadir mejoras, pero no puede garantizar que todo el flujo del formulario sea claro, lógico y usable.

Componentes interactivos no semánticos

En desarrollo frontend es habitual encontrar botones creados con div, tarjetas clicables sin estructura adecuada, menús personalizados sin soporte de teclado o modales que atrapan mal el foco.

Estos problemas deben resolverse en la construcción del componente. Usar el elemento HTML correcto suele ser la opción más robusta. Un botón debería ser un botón. Un enlace debería ser un enlace. Un campo de formulario debería tener su etiqueta correspondiente.

La accesibilidad no siempre consiste en añadir más código. Muchas veces consiste en usar mejor el código que ya existe.

Orden de foco incorrecto

La navegación por teclado depende de que el foco avance de forma lógica. Si al pulsar Tab el foco salta de manera incoherente, entra en elementos ocultos o desaparece, la experiencia se rompe.

Un overlay no puede conocer siempre la intención real de cada componente ni reconstruir de forma perfecta el flujo de interacción. Por eso, el orden de foco debe diseñarse y probarse desde el desarrollo.

Contenido dinámico que no se anuncia

En muchas webs modernas, el contenido cambia sin recargar la página. Aparecen mensajes, se abren modales, se actualizan resultados, se muestran notificaciones o se modifican partes de la interfaz.

Para que estos cambios sean accesibles, hay que gestionar correctamente el foco, los estados, los mensajes y los anuncios para tecnologías de asistencia. Un overlay puede no entender el contexto de cada actualización ni comunicarla de forma adecuada.

Textos alternativos generados sin contexto

Algunas herramientas prometen generar textos alternativos de forma automática. Aunque la automatización puede ayudar, no siempre entiende la función real de una imagen.

Una imagen puede ser decorativa, informativa, funcional o emocional. El texto alternativo no debe limitarse a describir lo que aparece visualmente, sino explicar lo que la imagen aporta en ese contexto.

Por ejemplo, una imagen de una persona usando un portátil puede ser decorativa en una sección, pero puede ser informativa si ilustra un paso concreto de un tutorial. Esa diferencia requiere criterio editorial.

El problema de vender accesibilidad como automatización total

La automatización puede ser útil en accesibilidad, pero tiene límites. Las herramientas automáticas ayudan a detectar errores frecuentes, como contrastes insuficientes, imágenes sin atributo alt o campos sin etiqueta. Sin embargo, no pueden evaluar toda la experiencia.

No pueden saber siempre si un texto alternativo es adecuado, si una instrucción es clara, si un flujo resulta comprensible, si un componente tiene sentido para una persona usuaria o si una interacción es frustrante.

Por eso, cuando una herramienta promete solucionar toda la accesibilidad de forma automática, conviene ser prudente.

La accesibilidad requiere contexto

Cada web tiene objetivos, contenidos, tecnologías y personas usuarias diferentes. No es lo mismo una tienda online que una web educativa, un blog técnico, una administración pública o una aplicación bancaria.

La accesibilidad depende del contexto. Depende de las tareas que se pueden realizar, de cómo se presenta la información, de cómo se gestionan los errores y de cómo se comporta la interfaz en situaciones reales.

Un overlay genérico no puede sustituir ese análisis.

La accesibilidad requiere pruebas reales

Las pruebas automáticas son necesarias, pero no suficientes. También hace falta revisar manualmente la web, navegar con teclado, comprobar lectores de pantalla, analizar formularios, probar menús, revisar modales y evaluar si los contenidos se entienden.

Además, siempre que sea posible, es recomendable contar con pruebas con personas usuarias, especialmente personas que utilicen tecnologías de asistencia en su día a día.

Qué hacer en lugar de depender de overlays

La alternativa no es “no hacer nada”. La alternativa es trabajar la accesibilidad de forma más sólida, aunque sea progresiva.

No hace falta resolver todos los problemas en una semana. Pero sí hace falta dejar de entender la accesibilidad como un botón externo y empezar a verla como parte del proceso de diseño y desarrollo.

Audita la web con una combinación de métodos

Un buen primer paso es realizar una auditoría que combine herramientas automáticas y revisión manual. Las herramientas automáticas ayudan a detectar errores básicos, pero la revisión manual permite analizar aspectos que requieren criterio.

Puedes revisar navegación por teclado, estructura de encabezados, formularios, textos alternativos, componentes interactivos, contraste, mensajes de error, modales y contenido dinámico.

Prioriza los flujos críticos

Si una web tiene muchos problemas, puede resultar abrumador. Por eso conviene priorizar.

Empieza por las partes más importantes: el formulario de contacto, el proceso de compra, el registro, el acceso a información esencial, las páginas con más tráfico o los flujos que tienen impacto directo en la conversión o en el servicio.

Corregir primero lo más importante permite mejorar la experiencia real de las personas sin esperar a una reforma completa.

Diseña componentes accesibles desde el inicio

Una de las formas más eficaces de mejorar la accesibilidad es trabajar desde los componentes. Botones, enlaces, formularios, menús, cards, modales, acordeones y pestañas deberían tener criterios de accesibilidad definidos.

Esto ayuda a que la accesibilidad no dependa de correcciones aisladas en cada página, sino de una base común más robusta.

Checklist básico para componentes accesibles

Antes de publicar un componente, conviene revisar al menos estas preguntas:

  • ¿Se puede usar con teclado?
  • ¿El foco es visible?
  • ¿Tiene un nombre accesible claro?
  • ¿Usa el elemento HTML correcto?
  • ¿El contraste es suficiente?
  • ¿Los estados se comunican correctamente?
  • ¿Los errores se entienden?
  • ¿Funciona sin depender solo del color?
  • ¿Respeta las preferencias de reducción de movimiento?

Este tipo de revisión aporta mucho más que instalar un overlay y confiar en que todo quede resuelto.

Forma al equipo

La accesibilidad no es responsabilidad exclusiva de desarrollo. También afecta a diseño, contenido, SEO, producto, legal, marketing y negocio.

Un texto de enlace poco descriptivo puede ser un problema de contenido. Un contraste bajo puede venir de diseño. Un modal inaccesible puede venir de desarrollo. Un flujo confuso puede venir de producto. Una promesa engañosa puede venir de negocio.

Por eso, formar al equipo es una de las inversiones más útiles.

Buenas prácticas para mejorar la accesibilidad web

Trabajar la accesibilidad no significa hacerlo todo perfecto desde el primer día. Significa tomar mejores decisiones y mantener una mejora continua.

Usa HTML semántico

El HTML semántico es una de las bases de la accesibilidad web. Encabezados, listas, botones, enlaces, formularios y secciones deben tener sentido estructural.

Cuando el HTML está bien construido, los navegadores y las tecnologías de asistencia pueden interpretar mejor el contenido.

Cuida el contraste y la legibilidad

El contraste no es solo una cuestión estética. Un texto con poco contraste puede ser difícil de leer para personas con baja visión, pero también para cualquier persona en una pantalla con poca calidad, en exteriores o en momentos de cansancio visual.

La legibilidad también depende del tamaño de fuente, el espaciado, la longitud de línea y la jerarquía visual.

Garantiza la navegación por teclado

Todo elemento interactivo debe poder utilizarse con teclado. Esto incluye menús, formularios, modales, botones, acordeones, pestañas y controles personalizados.

Además, el foco debe ser visible. Si una persona no sabe dónde está dentro de la página, no puede navegar con seguridad.

Escribe contenido claro

La accesibilidad también está en el lenguaje. Los textos deben ser comprensibles, los enlaces descriptivos, las instrucciones claras y los mensajes de error útiles.

No se trata de escribir de forma infantil ni de simplificar en exceso. Se trata de evitar ambigüedades innecesarias y ayudar a las personas a entender qué pueden hacer en cada momento.

Respeta las preferencias del usuario

La web puede adaptarse a preferencias del sistema, como la reducción de movimiento. Esto es especialmente importante cuando usamos animaciones, transiciones o efectos visuales.

Una experiencia accesible no obliga a todas las personas a consumir la misma interfaz de la misma forma. Respeta preferencias, contextos y necesidades diferentes.

Preguntas frecuentes sobre overlays de accesibilidad

¿Un overlay de accesibilidad hace que mi web cumpla WCAG?

No necesariamente. Un overlay puede añadir opciones visuales o intentar corregir algunos errores de forma automática, pero no garantiza el cumplimiento de WCAG. La conformidad depende de que el contenido, el código, la navegación y las funcionalidades cumplan criterios concretos de accesibilidad. Para comprobarlo, hace falta una evaluación seria que combine herramientas automáticas, revisión manual y pruebas reales.

¿Es malo instalar un widget de accesibilidad?

No siempre es malo por sí mismo, pero sí puede ser problemático si se presenta como una solución completa. Un widget puede ofrecer opciones de personalización útiles para algunas personas, pero no debe sustituir el trabajo de accesibilidad real. Si se instala, debe probarse con cuidado para asegurarse de que no interfiere con tecnologías de asistencia ni oculta problemas estructurales.

¿Cuál es la mejor alternativa a los overlays?

La mejor alternativa es trabajar la accesibilidad desde la base: auditoría, corrección del código, diseño inclusivo, revisión de contenidos, pruebas con teclado, pruebas con tecnologías de asistencia, formación del equipo y mantenimiento continuo. En lugar de depender de una capa externa, conviene construir una web accesible por defecto.

La accesibilidad no se superpone, se construye

Los overlays de accesibilidad han ganado popularidad porque prometen una respuesta rápida a un problema complejo. Pero una web accesible no se consigue añadiendo un botón flotante ni superponiendo una capa de JavaScript sobre una experiencia que ya tiene barreras.

La accesibilidad real se construye desde el diseño, el contenido, el código y las pruebas. Está en los pequeños detalles: un formulario bien etiquetado, un foco visible, un contraste adecuado, un enlace comprensible, una estructura clara, un mensaje de error útil y una navegación que no dependa exclusivamente del ratón.

El debate sobre los overlays no es solo técnico. También es ético. Tiene que ver con cómo entendemos la inclusión digital: como una responsabilidad real o como una apariencia de cumplimiento.

Por eso, los overlays pueden ser una ayuda puntual en algunos contextos, pero no deberían ocupar el lugar de una estrategia seria de accesibilidad. La web no debería ser accesible solo después de activar un panel. Debería ser accesible desde el principio.

Porque la accesibilidad no se superpone. La accesibilidad se diseña, se desarrolla, se prueba y se mantiene.