La accesibilidad web en el comercio electrónico consiste en garantizar que una persona que usa un lector de pantalla, que navega solo con el teclado o que tiene una configuración de pantalla para baja visión pueda explorar productos, entender qué está comprando y completar el pago sin toparse con una barrera que un usuario vidente con ratón no encontraría. Lo que está en juego es mayor que en un sitio de contenido habitual: un fallo de accesibilidad en una página de producto es una molestia, pero un fallo en el checkout bloquea directamente una venta. Acertar en los flujos principales importa más que perseguir cada criterio de éxito de WCAG por igual en todo el sitio.
Dónde se concentran los problemas de accesibilidad en las tiendas online
Un puñado de patrones propios del comercio electrónico explica la mayoría de las barreras reales. Las galerías de imágenes de producto con texto alternativo ausente o genérico (“imagen1.jpg”) dejan a los usuarios de lectores de pantalla sin poder saber qué están viendo. Los controles de filtro y ordenación, a menudo construidos como menús desplegables o deslizadores personalizados en lugar de elementos HTML nativos, con frecuencia son inalcanzables o inutilizables por teclado. Los selectores de talla y color en forma de “muestras” implementados como divs clicables en lugar de controles de formulario adecuados pueden ser directamente invisibles para las tecnologías de asistencia. Y los formularios de checkout, la parte con más en juego de toda la experiencia, suelen tener campos sin etiquetar, texto de marcador de posición usado en lugar de etiquetas reales (que desaparece en cuanto el usuario empieza a escribir) y errores de validación que aparecen visualmente pero nunca se anuncian a un lector de pantalla.
Páginas de producto
Toda foto de producto que aporte información necesita un texto alternativo con sentido que describa lo que un comprador realmente querría saber, como el color, el material, el ajuste o un rasgo distintivo, no una descripción exhaustiva de cada píxel. El precio, la disponibilidad y la valoración deben estructurarse para que un lector de pantalla los anuncie con claridad, en lugar de como una mezcla de números e iconos sin etiquetar. Los botones “añadir al carrito” necesitan nombres accesibles claros y únicos, sobre todo en páginas de categoría con muchos productos, donde un usuario de lector de pantalla podría oír “añadir al carrito” repetido una docena de veces sin forma de distinguir a qué producto corresponde cada uno.
Carrito y proceso de compra
Esta es el área de mayor prioridad en cualquier tienda, ya que es la parte del sitio directamente ligada a los ingresos. Cada campo de formulario, opción de envío y selector de método de pago necesita una etiqueta real asociada mediante código. Los mensajes de error deben anunciarse a las tecnologías de asistencia en cuanto aparecen, no solo mostrarse visualmente en texto rojo, y deben identificar con claridad a qué campo corresponde el error. Los contadores de cantidad, los campos de código promocional y cualquier indicador de progreso del checkout en varios pasos deben poder operarse solo con teclado, ya que los usuarios que dependen exclusivamente del teclado (no solo usuarios de lectores de pantalla, sino también muchas personas con discapacidad motriz) son visitantes habituales que una prueba centrada en el ratón no detecta.
Comparativa de herramientas pensadas para el comercio electrónico
Varios proveedores de accesibilidad se posicionan específicamente para casos de uso de comercio electrónico, y la mejor opción depende de cuánta parte de la solución quiera automatizarse frente a revisarse manualmente.
| Función | Wawsome | EqualWeb | AudioEye | UserWay |
|---|---|---|---|---|
| Enfoque | Bundles an AI-assisted accessibility widget with a continuous automated monitor and a human-reviewed accessibility checker, positioned around European compliance (EAA, EN 301 549) alongside WCAG and ADA. | Accessibility widget plus a manual remediation and auditing arm, offered across a wide range of subscription tiers from single small sites up to enterprise, multi-domain agreements. | Publicly traded accessibility company combining automated scanning, an adjustment widget, and human-in-the-loop manual testing and remediation delivered through its Accessibility Management Platform. | AI-driven accessibility widget with an in-house automated remediation engine, sold mainly as a self-serve script install with tiered plans and a separate professional audit add-on. |
| Precios | Free trial, then paid tiers (see wawsome.com/pricing-page for current rates) | Tiered subscription plans by monthly page views, with separate manual audit and remediation packages. | Tiered subscription plans plus managed services engagements; pricing published for standard tiers with custom enterprise quotes. | Freemium widget with paid tiers that unlock more automated checks; enterprise and professional audit services quoted separately. |
| Normas compatibles | WCAG 2.0, WCAG 2.1, WCAG 2.2, EAA, EN 301 549, ADA, Section 508 | WCAG 2.1, ADA, Section 508, EN 301 549, EAA | WCAG 2.1, WCAG 2.2, ADA, Section 508, EN 301 549 | WCAG 2.1, ADA, Section 508, EN 301 549 |
| Ideal para | SMEs and e-commerce sites selling into the EU; Public institutions preparing for EAA enforcement; Teams that want a widget plus a monitoring layer rather than a one-off scan | Organizations wanting a widget with an optional path to manual remediation at various budget levels | Mid-market and enterprise sites wanting automated coverage backed by human review | Very small sites wanting a no-cost starting point; Teams that want a widely recognized brand name |
Wawsome combina un widget asistido por IA con monitorización continua y un verificador con revisión humana, e incluye integración nativa con Shopify, lo que la convierte en una opción razonable para tiendas orientadas a la UE que quieren un mapeo con la EAA y la EN 301 549 junto al widget. EqualWeb y AudioEye combinan automatización con una vía hacia la corrección manual en varios niveles de precio, algo relevante para tiendas que en algún momento necesitarán una solución real para problemas concretos del checkout que un widget automatizado no puede resolver por sí solo. UserWay tiene amplio soporte de plugin en Shopify, WooCommerce y Wix, además de un plan gratuito, lo que encaja bien con una tienda pequeña que empieza, aunque su auditoría manual y el trabajo de VPAT se venden como complemento aparte en lugar de venir incluidos.
Lo que las herramientas automatizadas no detectan por sí solas
Los componentes de checkout personalizados, sobre todo los construidos con un framework de JavaScript en lugar de elementos de formulario HTML estándar, son el área donde más problemas tienen los widgets y escáneres automatizados, ya que no pueden reescribir una lógica de aplicación que no controlan. Un selector de cantidad o un autocompletado de dirección construido como un componente totalmente a medida debe probarse directamente con teclado y con un lector de pantalla, sin dar por hecho que queda resuelto solo porque haya un widget instalado en todo el sitio. Si su tienda usa un código de checkout muy personalizado, reserve presupuesto para una revisión manual de ese flujo concreto, sea cual sea la herramienta más amplia que utilice.
Compras desde el móvil e interacciones táctiles
Una gran parte del tráfico de comercio electrónico ocurre hoy en el móvil, y los patrones específicos de móvil introducen consideraciones de accesibilidad propias, más allá de un simple redimensionado responsivo. Los objetivos táctiles (botones, muestras de talla, controles de cantidad) deben ser lo bastante grandes para pulsarse con fiabilidad en el caso de usuarios con discapacidad motriz, y cualquier carrusel de imágenes deslizable o interacción basada en gestos necesita una alternativa accesible, ya que VoiceOver en iOS y TalkBack en Android navegan mediante gestos y no con un cursor de ratón, y un gesto de deslizamiento personalizado puede entrar en conflicto con los propios gestos de navegación del lector de pantalla si no se construye con cuidado.
Consideraciones internacionales y multidivisa
Las tiendas que venden en varios países o divisas suman una capa de complejidad que conviene planificar de forma directa. El formato de divisa y precio debe anunciarse con claridad e inequívocamente a un lector de pantalla, los atributos de idioma de la página deben coincidir con el idioma realmente mostrado para que la pronunciación y las herramientas de traducción funcionen correctamente, y cualquier selector de región o idioma debe ser un control real, etiquetado y operable por teclado, no un icono de bandera decorativo sin nombre accesible. Para las tiendas orientadas a la UE en particular, esto se solapa directamente con el cumplimiento de la EAA y la EN 301 549, ya que el comercio electrónico es explícitamente uno de los sectores que la EAA identifica como cubiertos.
Búsqueda, filtrado y funciones de personalización
Los paneles de búsqueda facetada y filtros son habituales en las páginas de categoría y a menudo son de las partes menos accesibles de una tienda, ya que suelen construirse con mucho JavaScript personalizado por motivos de rendimiento, y la accesibilidad se trata como algo secundario. Las casillas de filtro y los controles deslizantes de rango necesitan etiquetas reales y operabilidad por teclado, y cuando se aplica un filtro, el cambio resultante en el número de productos o resultados debe anunciarse a un lector de pantalla mediante una región activa ARIA, en lugar de actualizar la página en silencio. Las funciones de personalización como los carruseles de “vistos recientemente” o los widgets de recomendación tienen requisitos similares: necesitan una estructura de encabezados adecuada y controles etiquetados igual que cualquier otra parte de la página, aunque a menudo se añadan más tarde mediante un script de terceros que no formaba parte de las pruebas de accesibilidad originales de la plantilla.
Una lista de comprobación práctica para empezar
Recorra la plantilla de su página de producto, el carrito y todo el flujo de compra usando solo el teclado y un lector de pantalla como NVDA o VoiceOver, de principio a fin, como si estuviera comprando de verdad. Corrija primero los problemas de etiquetado y orden de foco que encuentre en el checkout, ya que ahí es donde una barrera le cuesta una venta, y luego avance hacia las páginas de producto y categoría. Vuelva a probar tras cualquier cambio de plantilla o de proveedor de checkout, ya que esos son los momentos en los que más a menudo se introducen regresiones de accesibilidad sin que nadie se dé cuenta.
Mantenga un registro sencillo de qué probó y cuándo, aunque sea informal. Ese registro resulta realmente útil de tres maneras: le permite comprobar si los problemas se van corrigiendo de verdad con el tiempo, en lugar de solo identificarse; le da algo concreto que mostrar si un cliente o un regulador pregunta alguna vez por sus prácticas de accesibilidad; y agiliza la siguiente revisión, porque sabrá qué plantillas y flujos ya se cubrieron y cuáles siguen pendientes.