Accesibilidad en el comercio electrónico: cómo hacer que tu tienda online cumpla con las WCAG

Imagina pasar diez minutos intentando comprar un regalo de cumpleaños en línea, solo para quedarte atascado en un menú desplegable que tu lector de pantalla no puede interpretar, o en un formulario de pago que atrapa el foco del teclado y no lo suelta nunca. Para los aproximadamente 61 millones de adultos con discapacidades en Estados Unidos, esto no es una hipótesis. Es una realidad diaria. Y para los comercios electrónicos, se traduce directamente en ingresos perdidos: las investigaciones sugieren que $2.3 billion en ingresos anuales en línea se evaporan debido a flujos de pago inaccesibles, mientras que el 71% de las personas con discapacidad abandonan de inmediato los sitios de comercio electrónico inaccesibles en lugar de intentar abrirse paso a la fuerza.

Por qué la accesibilidad en el comercio electrónico ya no es opcional

Las implicaciones legales y financieras en torno a la accesibilidad web nunca han sido tan altas, y el comercio electrónico está directamente en la mira. Solo en 2024, se presentaron 4,605 demandas relacionadas con sitios web bajo la ADA en los tribunales federales de EE. UU., y el sector del comercio electrónico soportó la mayor carga, representando aproximadamente entre el 68% y el 77% de todas las demandas, según la fuente de reporte. La tendencia se está acelerando: en la primera mitad de 2025 se presentaron 2,014 demandas por accesibilidad digital, un 37% de aumento respecto al mismo período de 2024, lo que pone al sector en camino de superar las 4,975 demandas para finales de año.

Los acuerdos extrajudiciales tampoco son triviales. Las resoluciones típicas oscilan entre $25,000 y $75,000, más los honorarios de abogados de ambas partes y el costo del trabajo de remediación que deberías haber hecho desde el principio. Más preocupante aún: en 2024, casi la mitad de todos los casos se presentaron contra empresas que ya habían sido demandadas antes y no habían corregido sus sitios de forma integral. Llegar a un acuerdo una vez no te protege de la siguiente demanda si el código subyacente sigue roto.

El panorama regulatorio también se está endureciendo a nivel global. La European Accessibility Act (EAA) pasó a ser exigible el 28 de junio de 2025 y cubre las plataformas de comercio electrónico que venden en mercados de la UE, con sanciones que pueden alcanzar hasta €100,000 o el 4% de los ingresos anuales en algunos estados miembros. En Estados Unidos, el Department of Justice publicó en abril de 2024 una norma final que exige formalmente WCAG 2.1 Nivel AA para los sitios web de gobiernos estatales y locales, y aunque las empresas privadas aún no se enfrentan a un estándar técnico federal vinculante, los tribunales y el DOJ utilizan de forma consistente WCAG como referencia de facto al evaluar reclamaciones bajo la ADA. El impulso es inconfundible: esperar a que haya regulaciones más claras es una estrategia de alto riesgo.

Más allá del riesgo legal, hay un mercado enorme y desatendido en juego. Las personas con discapacidad y sus familias representan una actividad económica global estimada en $13 trillion, y solo el ingreso disponible de la comunidad global de personas con discapacidad se estima en $1.9 trillion anuales. Las marcas que priorizan la accesibilidad también ven beneficios medibles en lealtad: un estudio encontró una tasa de retención de clientes un 18% más alta entre consumidores con discapacidad que se sentían bien atendidos. La accesibilidad no es caridad. Es buen negocio.

Entendiendo WCAG: el estándar que realmente importa

Las Web Content Accessibility Guidelines (WCAG), desarrolladas por el World Wide Web Consortium (W3C), son el marco técnico de referencia internacional para la accesibilidad digital. Están organizadas en torno a cuatro principios fundamentales, conocidos por el acrónimo POUR: el contenido debe ser Perceptible, Operable, Comprensible (Understandable) y Robusto. Cada principio se desglosa en criterios de éxito específicos y comprobables.

La versión actual, WCAG 2.2, se publicó en octubre de 2023 y añade nueve nuevos criterios de éxito a la versión anterior, manteniendo plena compatibilidad hacia atrás. Cumplir con WCAG 2.2 significa automáticamente que cumples con WCAG 2.1 y 2.0. Para la mayoría de los negocios de comercio electrónico, el objetivo debería ser la conformidad de Nivel AA: es el estándar mencionado en prácticamente todos los marcos regulatorios, el que los tribunales utilizan en litigios bajo la ADA y el nivel que realmente sirve a la gama más amplia de personas usuarias. El Nivel A es el mínimo indispensable, y el Nivel AAA, aunque loable, no es prácticamente alcanzable para la mayoría de los sitios transaccionales complejos.

Los nueve nuevos criterios de WCAG 2.2 añadieron varios requisitos con implicaciones directas y de alto impacto para el comercio minorista en línea: tamaños mínimos de objetivos táctiles (2.5.8), indicadores de foco que no queden ocultos por encabezados fijos (2.4.11), prevención de entradas redundantes en flujos de pago de varios pasos (3.3.7), autenticación accesible que no dependa de pruebas cognitivas como CAPTCHAs complejos (3.3.8) y colocación consistente de mecanismos de ayuda en todas las páginas (3.2.6). No son pautas abstractas: se corresponden directamente con los puntos de fricción que hacen que tus clientes abandonen sus carritos.

Los fallos de accesibilidad más comunes en sitios de comercio electrónico

Las investigaciones revelan de forma consistente que los sitios de comercio electrónico fallan en un conjunto predecible de aspectos. Entender estos patrones de fallo es el primer paso para priorizar tu trabajo de remediación. Según el informe WebAIM Million 2026, el texto con bajo contraste sigue siendo el problema más extendido, presente ahora en el 83.9% de las páginas de inicio, frente al 79.1% del año anterior. La página de inicio promedio contiene ahora 34 instancias distintas de texto con bajo contraste. Eso significa que tu banner de rebajas, las etiquetas de tus botones, tus precios: es muy probable que una parte significativa de tus clientes con baja visión simplemente no pueda leerlos.

Más allá del contraste, el Baymard Institute descubrió que, entre 33 sitios de comercio electrónico con mayor facturación evaluados frente a WCAG 2.1 AA: el 82% tenía problemas de accesibilidad con las imágenes de productos, el 73% tenía problemas con enlaces, el 64% tenía problemas con la navegación por teclado y el 58% tenía problemas con el marcado de los campos de formulario. No son casos marginales: son componentes fundamentales del recorrido de usuario de cualquier tienda en línea, desde la exploración hasta la compra.

Estas son las categorías de fallos que aparecen con más frecuencia tanto en auditorías como en demandas bajo la ADA dirigidas a tiendas en línea:

• Texto alternativo ausente o de mala calidad en imágenes de productos: Los lectores de pantalla anuncian el nombre del archivo de la imagen o la omiten por completo cuando falta el texto alternativo. Un buen texto alternativo describe lo que la imagen muestra realmente, no solo “imagen de producto”, sino algo como “Suéter azul marino de lana merino con cuello redondo, extendido sobre un fondo blanco”.
• Etiquetas de formulario y mensajes de error inaccesibles: Cada campo de entrada en tu proceso de pago debe tener un elemento <label> asociado de forma programática. Los mensajes de error que aparecen solo como texto rojo, sin descripción textual, son invisibles para las personas usuarias de lectores de pantalla y no cumplen los criterios de uso del color.
• Trampas de teclado en modales y paneles deslizables: Superposiciones de carrito, selectores de talla y modales de cupones que interceptan el foco del teclado pero no permiten que la persona usuaria salga con la tecla Escape son una barrera común y grave. Una persona que no puede salir del modal no puede completar su compra.
• Elementos interactivos no accesibles por teclado: Carruseles, menús desplegables personalizados, controles de cantidad y controles de zoom de imagen construidos sin roles ARIA ni controladores de eventos de teclado simplemente no existen para quienes usan solo el teclado.
• Actualizaciones dinámicas del carrito no anunciadas a la tecnología de asistencia: Cuando una persona añade un artículo a su carrito y la cantidad del carrito cambia mediante JavaScript sin recargar la página, los lectores de pantalla no se enteran a menos que lo anuncies explícitamente usando una región ARIA en vivo.
• Tamaños insuficientes de objetivos táctiles: WCAG 2.2 exige que los elementos interactivos tengan al menos 24×24 píxeles CSS. Los iconos pequeños de “Añadir a la lista de deseos”, los botones de cierre de modales y las muestras de color de variantes suelen incumplir este requisito en dispositivos móviles.
• Indicadores de foco ocultos por encabezados fijos o contenido superpuesto: Cuando una persona navega con la tecla Tab hasta un enlace o botón y el anillo de foco queda oculto bajo una barra de navegación persistente o un banner de cookies, no puede saber dónde se encuentra en la página.

Una regla práctica útil: si no puedes completar todo tu flujo de compra —desde la página de aterrizaje hasta la confirmación del pedido— usando solo el teclado y sin ratón, tu proceso de pago no es accesible.

Una hoja de ruta de accesibilidad página por página para tu tienda

La accesibilidad en el comercio electrónico no es un único problema, sino un conjunto de problemas específicos y dependientes del contexto que varían según el tipo de página. El enfoque de remediación más eficaz recorre el viaje del cliente de forma sistemática, empezando por las áreas de mayor impacto.

Páginas de listado de productos (PLPs): Asegúrate de que los controles de filtrado —casillas de verificación, deslizadores, menús desplegables— se puedan usar con el teclado y tengan estados de foco visibles. Si los filtros actualizan los resultados de forma dinámica, envuelve la región de resultados en una región aria-live para que los lectores de pantalla anuncien que la lista de productos ha cambiado. Cada enlace de tarjeta de producto debe tener texto descriptivo (no solo “Ver” o “Más información”) y las imágenes de producto necesitan texto alternativo significativo.

Páginas de detalle de producto (PDPs): Los selectores de variantes (talla, color, material) son un punto de fallo notorio. Los botones de opción personalizados o los botones usados como interruptores necesitan roles y estados ARIA adecuados. Si utilizas una tabla de tallas en un modal, ese modal debe gestionar el foco correctamente: atraparlo dentro del diálogo cuando está abierto y devolverlo al elemento disparador cuando se cierra. Los videos de producto deben tener subtítulos; las descripciones de audio son necesarias cuando se transmite información visual significativa sin narración.

Carrito de compra y mini-carrito: Cuando una persona añade un artículo al carrito, la confirmación debe anunciarse a los lectores de pantalla mediante una región aria-live con role='status' o role='alert'. Los controles de cantidad deben poder usarse con el teclado, y el botón “Eliminar artículo” debe tener un nombre accesible único y descriptivo para cada línea de producto, no solo “Eliminar” repetido cuatro veces para cuatro productos distintos.

Flujo de pago: Aquí es donde se encuentran las infracciones de WCAG de mayor riesgo y de donde surgen las demandas más costosas. Bajo el modelo de conformidad de WCAG, todas las páginas de un proceso deben cumplir: no puedes tener una página de producto accesible y una pantalla de pago inaccesible y afirmar que cumples. Los requisitos clave incluyen: todos los campos de formulario deben tener etiquetas visibles persistentes (no solo texto de marcador de posición, que desaparece cuando la persona empieza a escribir), los mensajes de error deben identificar el campo específico y describir en texto qué salió mal, los atributos de autocompletado (autocomplete='email', autocomplete='cc-number', etc.) deben estar presentes para ayudar a personas con discapacidades cognitivas y motoras, y todo el flujo debe poder completarse sin ratón. WCAG 2.2 también prohíbe exigir que las personas vuelvan a introducir información que ya han proporcionado en la misma sesión, por lo que si tu proceso de pago solicita la dirección de facturación después de que el cliente acaba de introducir la dirección de envío, esa información debería poder rellenarse automáticamente.

Inicio de sesión y registro de cuenta: El criterio de Autenticación Accesible (3.3.8) de WCAG 2.2 significa que no puedes exigir que las personas resuelvan una prueba de función cognitiva —como un CAPTCHA de imagen estándar— como único método de autenticación. Ofrece alternativas como enlaces mágicos por correo electrónico, códigos por SMS o OAuth de terceros. Si utilizas CAPTCHA, una alternativa de audio es el mínimo, pero quienes abogan por la accesibilidad cognitiva recomiendan abandonar por completo el CAPTCHA en favor de métodos menos gravosos.

Implementación a nivel de código: cómo se ve realmente un comercio electrónico accesible

La accesibilidad es, en última instancia, un problema de código, y la orientación abstracta solo llega hasta cierto punto. Así es como se ve una implementación correcta para algunos de los patrones de comercio electrónico más comunes.

Para un enlace de salto de navegación (esencial para quienes usan teclado y no quieren recorrer con Tab todo tu encabezado en cada página):

<a href='#main-content' class='skip-link'>Skip to main content</a>

<style>
  .skip-link {
    position: absolute;
    top: -40px;
    left: 0;
    background: #000;
    color: #fff;
    padding: 8px 16px;
    z-index: 9999;
    text-decoration: none;
  }
  .skip-link:focus {
    top: 0;
  }
</style>

<main id='main-content' tabindex='-1'>
  <!-- your page content -->
</main>

Para un anuncio de actualización del carrito que los lectores de pantalla detectarán automáticamente cuando se añada un artículo:

<!-- Place this in your page HTML -->
<div
  role='status'
  aria-live='polite'
  aria-atomic='true'
  class='visually-hidden'
  id='cart-announcement'
></div>

<!-- Then in your JavaScript, after a cart update: -->
<script>
  function announceCartUpdate(message) {
    const region = document.getElementById('cart-announcement');
    region.textContent = '';
    // Force the browser to register the DOM change before updating
    requestAnimationFrame(() => {
      region.textContent = message;
    });
  }
  // Example usage:
  announceCartUpdate('Blue Linen Shirt added to cart. Cart now contains 3 items.');
</script>

Para un indicador de foco compatible con WCAG 2.2 que cumpla los requisitos de contraste y tamaño:

<style>
  /* Remove browser default and replace with a strong custom indicator */
  :focus-visible {
    outline: 3px solid #0057b8;
    outline-offset: 3px;
    border-radius: 2px;
  }
  /* Ensure sticky header doesn't obscure focused elements (WCAG 2.4.11) */
  :focus {
    scroll-margin-top: 80px; /* match your header height */
  }
</style>

Para etiquetas de formulario correctamente asociadas y mensajes de error en línea en el proceso de pago:

<div class='form-field'>
  <label for='email'>Email address <span aria-hidden='true'>*</span></label>
  <input
    type='email'
    id='email'
    name='email'
    autocomplete='email'
    aria-required='true'
    aria-describedby='email-error'
  />
  <span
    id='email-error'
    role='alert'
    class='error-message'
  ><!-- Populated by JS on validation failure --></span>
</div>

Pruebas: las herramientas automatizadas son un punto de partida, no la meta

Uno de los conceptos erróneos más peligrosos en el cumplimiento de la accesibilidad es creer que los escáneres automatizados pueden decirte si tu sitio es accesible. No pueden. Las herramientas automatizadas pueden detectar aproximadamente el 30–40% de los problemas de WCAG, como atributos alt ausentes, fallos evidentes de contraste y etiquetas de formulario inexistentes. El 60–70% restante de los problemas requiere juicio humano: ¿este texto alternativo describe realmente la imagen de forma significativa? ¿El orden de lectura es lógico cuando se navega con un lector de pantalla? ¿El mensaje de error es realmente útil o solo dice “entrada no válida”?

Una estrategia de pruebas realista para una tienda de comercio electrónico utiliza varias capas. Empieza con un escáner automatizado —herramientas como axe-core, WAVE o Lighthouse— ejecutado sobre cada plantilla de página (PLP, PDP, carrito, pago, cuenta). Esto saca a la luz rápidamente los problemas más obvios. Luego realiza una sesión usando solo el teclado: desconecta el ratón e intenta completar una compra completa. Recorre todo con la tecla Tab. Intenta abrir y cerrar modales. Intenta actualizar la cantidad del carrito. Intenta aplicar un código de cupón. Si te quedas atascado en algún punto, eso es un fallo.

Después, haz pruebas con al menos un lector de pantalla. NVDA con Firefox y VoiceOver con Safari son las combinaciones más representativas para la mayoría de las audiencias. Escucha cómo se anuncia tu página de producto. ¿El lector de pantalla transmite toda la información que obtendría una persona vidente? ¿El flujo de pago tiene sentido cuando se lee de forma lineal? Por último, y lo más valioso, haz pruebas con personas usuarias reales con discapacidad. Las herramientas automatizadas y las pruebas de desarrolladores siempre pasarán por alto cosas que las personas reales encuentran debido a la forma específica en que interactúan con la tecnología de asistencia.

Para el cumplimiento continuo, las comprobaciones de accesibilidad deben integrarse en tu pipeline de CI/CD para que las nuevas implementaciones de código se analicen automáticamente antes de salir a producción. Los sitios de comercio electrónico cambian constantemente —nuevas promociones, nuevas categorías de productos, nuevos pasos en el proceso de pago— y cada cambio es una oportunidad para introducir nuevas barreras. La accesibilidad es un proceso, no un proyecto puntual.

La cuestión del widget de superposición: lo que necesitas saber

Si has estado buscando soluciones de accesibilidad, casi con seguridad te has encontrado con widgets de superposición: herramientas JavaScript que prometen hacer tu sitio conforme añadiendo una capa de correcciones automatizadas sobre tu código existente. Algunos productos comercializan esto como una solución de una sola línea. La realidad es más complicada, y el perfil de riesgo es significativo.

En 2024, más de 1,000 empresas fueron demandadas a pesar de tener widgets de accesibilidad instalados en sus sitios web, lo que representó más del 25% de todos los casos bajo la ADA ese año. La razón es sencilla: las superposiciones añaden una capa de JavaScript sobre HTML defectuoso, pero los lectores de pantalla se encuentran con las barreras de accesibilidad subyacentes antes de que los scripts de superposición puedan intervenir, si es que intervienen. Los widgets de superposición también pueden introducir sus propios problemas de accesibilidad, incluidos diálogos modales que atrapan el foco y funciones que entran en conflicto con la configuración de la propia tecnología de asistencia de la persona usuaria.

En enero de 2025, la Federal Trade Commission obligó a AccessiBe —uno de los proveedores de superposiciones más promocionados— a pagar $1 million para resolver acusaciones de que había tergiversado la capacidad de su producto para hacer que los sitios web cumplieran con WCAG. Ningún tribunal ha aceptado un widget de superposición como prueba de cumplimiento de la ADA.

Esto no significa que todas las herramientas de accesibilidad del lado del cliente carezcan de valor. Un SDK de accesibilidad bien construido —uno que complemente una remediación genuina a nivel de código en lugar de sustituirla— puede aportar un valor real: ofrecer a las personas usuarias un panel de preferencias donde puedan ajustar el contraste, el tamaño de la fuente o la configuración de movimiento; proporcionar una declaración de accesibilidad con un canal claro de comentarios; y aplicar remediaciones en áreas donde el acceso completo al código es limitado (como ciertos widgets de terceros). La distinción es enormemente importante: una herramienta que ayuda a las personas usuarias y complementa una remediación adecuada es categóricamente distinta de una que afirma reemplazarla. Soluciones como Accsible están diseñadas con esta filosofía: proporcionar un SDK que mejore la experiencia de las personas visitantes que necesitan adaptaciones, dejando claro al mismo tiempo que el cumplimiento real se construye en el código.

Crear un programa de accesibilidad, no solo corregir errores

El camino más sólido hacia el cumplimiento de WCAG —y el menos propenso a resultar en demandas repetidas— consiste en tratar la accesibilidad como una práctica organizacional continua en lugar de un proyecto técnico puntual. La remediación sin mejora de procesos es como achicar agua de un barco con una vía de agua sin reparar el agujero.

Empieza publicando una Declaración de Accesibilidad en tu sitio. Esta página debe describir el estándar que estás intentando cumplir (WCAG 2.2 Nivel AA), las limitaciones conocidas de tu implementación actual, cómo las personas pueden informar de barreras de accesibilidad y con qué rapidez responderás. Esto demuestra buena fe, ofrece a las personas usuarias una vía para pedir ayuda y es un requisito explícito en la legislación de la UE. Acompáñala de un mecanismo de comentarios genuino: una dirección de correo electrónico o un formulario que realmente llegue a alguien con autoridad para corregir problemas.

Forma a todo tu equipo, no solo a las personas desarrolladoras. Diseñadores que entienden las relaciones de contraste y los requisitos de estados de foco producirán maquetas accesibles. Creadores de contenido que saben cómo redactar texto alternativo eficaz dejarán de dejar campos en blanco. Product managers que entienden WCAG se opondrán cuando una funcionalidad propuesta no tenga un camino por teclado. El conocimiento de accesibilidad distribuido en un equipo es mucho más duradero que una sola persona especialista en accesibilidad intentando detectarlo todo al final.

Por último, documenta tus hallazgos de auditoría, las correcciones aplicadas y los resultados de las pruebas. Esto crea un rastro de auditoría valioso tanto internamente —para seguir el progreso— como externamente, como prueba de esfuerzos de cumplimiento de buena fe si alguna vez te enfrentas a un desafío legal. Una de cada cuatro demandas en 2024 involucró a demandados reincidentes que habían sido demandados y habían llegado a un acuerdo sin corregir realmente el problema. Un programa de remediación documentado y exhaustivo es tu mejor defensa contra ese resultado.

Conclusiones clave

• El comercio electrónico es el objetivo principal de los litigios por accesibilidad. Al representar aproximadamente el 70% de todas las demandas por accesibilidad digital bajo la ADA, las tiendas en línea enfrentan el mayor riesgo en el panorama digital. Los acuerdos extrajudiciales suelen situarse entre $25,000 y $75,000 más los costos de remediación, y un acuerdo previo no te protege de demandas posteriores si las barreras persisten.
• Apunta a WCAG 2.2 Nivel AA: cubre 2.1 y 2.0 automáticamente. WCAG 2.2 es compatible hacia atrás, por lo que aspirar al estándar más reciente te da la cobertura legal más amplia en los tribunales de EE. UU., la European Accessibility Act de la UE y la mayoría de las demás jurisdicciones del mundo.
• Corrige primero el embudo de compra. El flujo de pago —desde el carrito hasta la confirmación del pedido— es donde se encuentran las barreras de mayor riesgo y donde las personas con discapacidad tienen más probabilidades de abandonar. Prioriza la accesibilidad por teclado, las etiquetas de formularios, el manejo de errores y los anuncios de contenido dinámico en cada paso del proceso de pago.
• Las herramientas automatizadas detectan solo el 30–40% de los problemas de WCAG. Complementa el análisis automatizado con pruebas usando solo el teclado, pruebas con lectores de pantalla y sesiones con personas usuarias reales. Integra las comprobaciones de accesibilidad en tu pipeline de CI/CD para que el código nuevo no introduzca regresiones.
• La accesibilidad es un programa, no un parche. Forma a tus diseñadores, desarrolladores y equipo de contenidos. Publica una Declaración de Accesibilidad con un canal real de comentarios. Documenta tu trabajo de remediación. Incorpora la accesibilidad en tu proceso de desarrollo para que las correcciones se mantengan a medida que tu tienda evoluciona.