Un cliente que realiza un pago con tarjeta mediante un terminal de pago portátil.

Descripción de la imagen: Un cliente realiza un pago con tarjeta mediante un terminal de pago portátil.

El proceso de pago en el comercio electrónico: el ámbito más conflictuoso de Internet

AIOPSGROUP · Inteligencia en materia de accesibilidad
Análisis de litigios · Demandas presentadas ante tribunales federales · 2007-2026

El proceso de pago en el comercio electrónico: el ámbito más controvertido de Internet

Un conjunto de datos con 8.788 demandas federales por accesibilidad web revela una tendencia poco halagüeña. Los mismos pocos errores llegan a la fase de producción en las mismas pocas etapas, y los mismos pocos demandantes los detectan. De los 81 509 problemas que los abogados han catalogado en los escritos judiciales, más de 4050 se concentran en las cinco áreas que convierten a un visitante en comprador: el carrito, la dirección, el pago, los mensajes de error y el propio botón de finalización de la compra.

4,050
problemas relacionados con la fase de pago mencionados en los documentos judiciales (carrito, dirección, pago, añadir al carrito, proceso de pago)
7.4×
Aumento de las demandas presentadas anualmente, 2021 → 2025 (466 → 3.449 casos)
97
mediana de días transcurridos desde la presentación de la reclamación hasta el cierre del caso (lo que sugiere un acuerdo)
83.4%
Todos los casos cerrados se resuelven en menos de seis meses: los demandados pagan o subsanan la infracción, y luego siguen adelante. El proceso está diseñado para gestionar un gran volumen de casos, no para generar disputas.

Por qué el paso por caja es la infracción que te sale cara

Las demandas por accesibilidad web se interponen en todos los niveles de un sitio web: página de inicio, navegación, pie de página, buscador. Sin embargo, en las contadas ocasiones en que una demanda llega a la fase de resolución, a los tribunales no les preocupan las barreras estéticas, sino las transaccionales. Un comprador ciego que no puede encontrar un banner destacado no ha perdido nada, en términos jurídicos muy claros. Un comprador ciego que no puede completar una compra se ha visto privado de un servicio que el vendedor ofrecía a todos los demás visitantes. Esa es la formulación clásica de una infracción del Título III, y es el mismo patrón fáctico que se repite en todas las cartas de reclamación que redactan los abogados demandantes.

Por eso, las áreas más mencionadas del conjunto de datos no son las que generan más quejas en general. «General / Sin clasificar» es, con diferencia, la categoría con más incidencias (38 671). Pero si nos basamos en el dinero en juego por cada fallo, el embudo de pago genera más litigios que todas las demás categorías juntas. Cada campo CVC sin etiquetar es una denegación de servicio. Cada «Pedido confirmado» sin previo aviso es una transacción que el usuario no puede demostrar que haya realizado. Cada ventana modal que atrapa el foco en el paso «Aplicar cupón» es un descuento por el que el usuario de un lector de pantalla ha pagado el precio completo para saltárselo.

La función de litigio

En un tribunal federal de Estados Unidos, la cuestión no es «¿es accesible la página de inicio?», sino «¿podía el demandante comprar lo que vendía el demandado?». El proceso de pago es el único punto en el que la respuesta es binaria, y el único en el que resulta sencillo alegar los daños y perjuicios.

El conjunto de datos

El análisis en el que se basa este artículo se apoya en dos corpus independientes. El primero es una muestra estructurada de PACER que recoge 8.788 causas civiles federales interpuestas en virtud de la Ley de Estadounidenses con Discapacidades y de las leyes estatales equivalentes entre enero de 2007 y abril de 2026, en la que cada causa está vinculada a sus demandantes, demandados, fecha de presentación y fecha de resolución. El segundo es una extracción paralela de 81 509 cuestiones de accesibilidad distintas extraídas del texto de esos escritos: las frases concretas que los abogados escribieron para describir lo que sus clientes no podían hacer.

Ambos datos juntos nos permiten responder a preguntas que una sola fuente no puede resolver. No solo sabemos qué sitios web fueron demandados, sino también qué fallos señalaron los abogados ante el tribunal, y en qué punto del recorrido del usuario se produjeron dichos fallos. Para este artículo, hemos filtrado el corpus de incidencias en cinco categorías del embudo de compra: FLUJO DE PAGO, CARRITO DE LA COMPRA, AÑADIR AL CARRITO, PAGO y GESTIÓN DE DIRECCIONES. En conjunto, estas cinco áreas suman 4.050 incidencias —aproximadamente el 5 % del corpus—, pero son las que presentan una relación causal más fuerte con el perjuicio determinante.

Nota sobre el alcance La cifra de 8.788 incluye casos relacionados con la accesibilidad en cualquier plataforma digital; no todos ellos se refieren al comercio electrónico minorista. Sin embargo, los sitios de comercio electrónico y las franquicias que los gestionan predominan en la lista de demandados: Marriott, TJX, Tapestry, Wolverine World Wide, Five Below, Walgreens, Target, Genesco, Sherwin-Williams, GameStop y Caleres aparecen cada uno de ellos cinco o más veces.

La curva que nadie tuvo en cuenta en el plan del cuarto trimestre

Antes de analizar el interior del embudo, conviene determinar hasta qué punto se ha agudizado la situación en el exterior. Las solicitudes anuales se han multiplicado por diez desde 2020 y siguen aumentando a un ritmo acelerado. La cifra de 2026 que se muestra a continuación solo abarca el primer trimestre; según las proyecciones para todo el año, se prevé que supere las 4.500, lo que supone casi diez veces la cifra de referencia de 2021.

Fig. 1 Demandas federales por accesibilidad web presentadas por año, n=8.788
2019
6
0.07%
2020
45
0.51%
2021
466
5.30%
2022
755
8.59%
2023
1,018
11.58%
2024
2,156
24.53%
2025
3,449
39.25%
2026
878 ▱
Solo el primer trimestre

▱ Datos parciales de 2026: solicitudes presentadas hasta abril de 2026. Al ritmo registrado en el primer trimestre, el año va camino de alcanzar unas 3.500 solicitudes, en línea con la tendencia de 2025.

Hay dos puntos que conviene tener en cuenta. En primer lugar, el año de inflexión es 2021, que coincide con el auge del comercio electrónico tras la pandemia y con una oleada de sentencias de tribunales estatales (en particular , el caso Robles contra Domino’s, cuya revisión fue denegada por el Tribunal Supremo en 2019) que llevaron a los tribunales federales del Noveno Circuito a interpretar que los sitios web entran dentro de la definición de «lugares de uso público» del Título III. En segundo lugar, el crecimiento no se ha estancado. Cada año desde 2021 ha marcado un nuevo récord, y cada nuevo récord anual se ha alcanzado mientras el Título III ha permanecido, formalmente, sin regular los sitios web comerciales privados.

El embudo dentro del embudo

De los 81 509 casos catalogados a partir de las denuncias presentadas, 4050 se encuadran en una de las cinco categorías del embudo de compra que se indican a continuación. La distribución proporcional se ajusta casi a la perfección al embudo de conversión canónico: se registran más casos en las primeras etapas del proceso, y en cada paso se pierden tanto usuarios legítimos como se superan obstáculos legales.

Fig. 2 Número de problemas por etapa del embudo de compra, n=4.050
Proceso de pago (general)40,9 %
1.656 números
Página del carrito de la compra25,2 %
1.022 números
Añadir al carrito17,7 %
718 números
Pago12,9 %
524 números
Gestión de direcciones3,2 %
130 números

La categoría «Proceso de pago» es la más amplia, ya que la mayoría de las reclamaciones describen la experiencia como un único recorrido. Pero el desglose es revelador: el carrito y la función «Añadir al carrito» juntas (1.740 casos) generan ligeramente más reclamaciones litigadas que la propia página de pago. Esto se debe en parte a que el carrito es donde se produce la primera acción irreversible: una vez que el usuario de un lector de pantalla no puede confirmar que se ha añadido un artículo, cada paso posterior se realiza a ciegas. Los problemas que surgen al principio se agravan a medida que se avanza en el proceso.

Los cinco errores, por orden de frecuencia

Al comparar los 4.050 problemas detectados en la fase de pago con sus descripciones en texto sin formato, se observa que cinco tipos de fallos constituyen la mayor parte de las reclamaciones de los demandantes. A continuación los enumeramos por orden de frecuencia de aparición en los escritos, junto con los criterios de las WCAG que los abogados citan con mayor frecuencia.

№ 1
«Lo añadí al carrito, pero nunca me di cuenta de que estaba ahí».
Error al añadir al carrito en 639filings

Al añadir un artículo al carrito se activa una confirmación visual —una ventana emergente, la aparición de un minicarrito o el aumento del recuento en la insignia— que los lectores de pantalla no anuncian. El usuario vuelve a hacer clic, duplica el pedido o desiste. Esta es la barrera más citada en las reclamaciones relacionadas con el carrito.

Mensajes de estado según WCAG 4.1.3WCAG 4.1.2 nombre, función, valor
№ 2
«El campo del código promocional no me dio ninguna indicación cuando falló».
566 solicitudes relacionadas con cupones de referencia o códigos de descuento

Los campos para introducir códigos de descuento no están etiquetados, no se indican los posibles errores y la validación en tiempo real solo se muestra como texto en color. Los demandantes suelen alegar que pagaron el precio completo porque no pudieron acceder al canal de descuentos, lo que supone un perjuicio económico concreto.

ID de error de WCAG 3.3.1Sugerencias para el error WCAG 3.3.3
№ 3
«Apareció una ventana emergente. Yo, en cambio, seguí concentrado».
Errores de enfoque en la ventana modal o superpuesta de 511filings

Los cuadros de diálogo de confirmación de dirección, las ventanas emergentes del tipo «¿Estás seguro?», las ofertas de productos complementarios y los retos CAPTCHA se muestran en pantalla, pero nunca reciben el foco de forma automática. Los usuarios que utilizan el teclado o lectores de pantalla no pueden cerrarlos ni seguir adelante.

WCAG 2.4.3: orden de enfoqueWCAG 2.1.2: sin trampas de teclado
№ 4
«Mi CVC era incorrecto. En el formulario no ponía nada».
468 registros hacen referencia a estados de error no anunciados

Los campos obligatorios que se han dejado en blanco, las tarjetas de crédito rechazadas por no cumplir con la expresión regular y las discrepancias en la dirección solo se indican mediante marcos rojos o validadores de texto que desaparecen. El usuario de un lector de pantalla envía el formulario, no recibe ninguna respuesta y da por hecho que el pedido se ha procesado. El criterio WCAG 3.3.1 es el más citado en las notificaciones sobre el proceso de pago.

ID de error de WCAG 3.3.1Etiquetas WCAG 3.3.2
№ 5
«El campo se mostró como "en blanco"».
330 registros hacen referencia a campos de entrada sin etiquetar

Número de tarjeta, fecha de caducidad, código postal, «Igual que la dirección de facturación»: los campos sin etiquetar se anuncian como «en blanco» o «editar texto». Los usuarios no pueden distinguir qué campo es cuál, los rellenan en el orden incorrecto y provocan errores de validación que, a su vez, no se anuncian (véase el n.º 4).

WCAG 1.3.1: información y relacionesWCAG 4.1.2: nombre, función y valor
№ 6
«Tuve que volver a empezar el proceso de pago».
163 expedientes relacionados con el reingreso forzoso

Cuando un solo campo no supera la validación, algunos procesos de pago borran y reinician todo el formulario al recargar la página. Para los usuarios que tardaron seis minutos en completarlo la primera vez con tecnología de apoyo, esto supone una barrera que no existe para los compradores videntes que utilizan el ratón: el típico ejemplo de acceso desigual.

Prevención de errores según WCAG 3.3.4WCAG 2.5.3: etiqueta en el nombre

Los criterios que los abogados mencionan realmente

La mayoría de las demandas no citan explícitamente los criterios de las WCAG, sino que describen los síntomas. Sin embargo, cuando los abogados sí citan criterios específicos en las alegaciones relativas a la fase de pago, la distribución presenta un sesgo considerable. Seis criterios representan el 89 % de todas las citas explícitas; los más de sesenta criterios restantes de las WCAG 2.2 apenas se mencionan de forma marginal.

Fig. 3 Criterios de las WCAG 2.x citados explícitamente en 4.050 formularios de pago
WCAG Nombre del criterio Nivel Citado en Compartir Donde se nota en el momento de pagar
3.3.1 Identificación de errores A 104 32.5% El formulario no ha señalado los campos obligatorios ni los errores de validación
2.4.3 Pedido prioritario A 72 22.5% Las ventanas modales, los cuadros de diálogo y las transiciones entre pasos no cambiaban el foco
2.1.1 Teclado A 43 13.4% Los botones de PayPal y «Exprés» no se pueden seleccionar sin ratón
4.1.3 Mensajes de estado AA 26 8.1% «Añadido al carrito», «descuento aplicado», «pedido realizado» (sin sonido)
4.1.2 Nombre, función, valor A 23 7.2% Los widgets personalizados de radio y selección no revelan su estado a AT
3.3.2 Etiquetas o instrucciones A 18 5.6% El CVC, el código postal y la opción «Igual que la dirección de facturación» aparecen como «en blanco»
1.3.1 Información y relaciones A 7 2.2% Los indicadores de paso no están visibles; agrupación de campos obligatorios
2.4.7 Enfoque visible AA 4 1.2% No se destaca visualmente los botones de pago
2.5.3 Etiqueta en el nombre A 1 0.3% Discrepancias en el control por voz entre el nombre visible y el nombre accesible
Lee la tabla con atención

Solo 320 de los 4.050 problemas (aproximadamente el 8 %) citan un criterio de las WCAG por su número. El resto describe el síntoma en lenguaje sencillo. La conclusión: aunque presentes un informe de auditoría WCAG 2.2 AA impecable, a tu equipo de ingeniería se le seguirá evaluando en función de los síntomas: «el usuario no pudo completar la compra» es el criterio que le importará a un tribunal, no «se ha incumplido el criterio de éxito 3.3.1».

Lo que escribieron realmente los demandantes

El conjunto de datos se ha elaborado a partir de los escritos presentados ante los tribunales. Las frases que figuran a continuación se han extraído de dichos escritos; se han anonimizado para eliminar las referencias a los lugares, pero por lo demás no se han modificado. Resultan útiles porque transmiten a los equipos de ingeniería lo que los usuarios describen, con sus propias palabras, tal y como los abogados han plasmado esas descripciones en las pruebas documentales.

«Todos los campos de texto se anuncian como “en blanco”. Las opciones del menú desplegable “Tamaño” no son accesibles para los usuarios que utilizan únicamente el teclado.» – Alegación sobre los formularios, demanda ante el Tribunal de Distrito de Nueva York (S.D.N.Y.)
«Al hacer clic en el botón "Añadir al carrito", aparece un mensaje de confirmación junto al botón. Este mensaje es el único indicio de que el artículo se ha añadido correctamente, y no se anuncia de forma audible.» – Denuncia sobre la función «Añadir al carrito»
«Cuando el usuario intenta finalizar la compra y no introduce un código postal, no aparece ningún mensaje que indique el error.» – Alegación relativa a la gestión de direcciones, repetida en 11 demandas contra distintos demandados
«El demandante no pudo determinar si los campos del formulario eran obligatorios («Requerido») en la página de pago. La falta de instrucciones detalladas a la hora de rellenar el formulario impidió que el demandante pudiera enviarlo correctamente.» – Alegación relativa al proceso de pago
«El botón de PayPal no se puede manejar con el teclado (página de pago): el botón de PayPal recibe el foco visual, pero no se puede activar con la tecla Intro.» – Reclamación sobre el pago, con referencia a WCAG 2.1.1
«El demandante no podía volver atrás y corregir los campos del formulario sin tener que recargar toda la página y empezar de nuevo.» – Alegación relativa al proceso de pago, caso del Distrito Sur de Nueva York

Lo que unifica el conjunto de datos no es la sofisticación técnica. Las barreras que mencionan los abogados no son nuevas ni oscuras: se trata de la misma docena de patrones, que se repiten en miles de demandas presentadas contra miles de demandados. Los abogados demandantes han industrializado de manera efectiva la detección de errores que los equipos de ingeniería no han detectado, ya que estos no han realizado sus propias comprobaciones con un lector de pantalla.

El fenómeno de los 97 días

De los 8.788 casos del conjunto de datos, 6.945 se habían cerrado en abril de 2026 y contaban con fechas válidas de presentación y resolución. La duración de estos casos constituye una de las distribuciones más reveladoras del corpus. La mediana del tiempo transcurrido desde la denuncia hasta el cierre es de 97 días; el 83,4 % de todos los casos se cierran en menos de seis meses.

Fig. 4 Distribución de la duración de los casos desde su presentación hasta su cierre, n = 6.945
7.7%
< 30d534
37.6%
30–90 d 2609
38.1%
90–180 días 2643
12.6%
180–365d872
3.3%
1–2y227
0.9%
>2 años y 60

Los casos que se resuelven en menos de 180 días, casi sin excepción, no dan lugar a una sentencia sobre el fondo del asunto. Se resuelven mediante un acuerdo. La forma de esta distribución refleja la estrategia de todo el colectivo de abogados demandantes: presentar un gran volumen de demandas, llegar rápidamente a un acuerdo y evitar el reducido número de sentencias definitivas que permitirían a los demandados diferenciar sus resoluciones de las de otras empresas. La mediana de los acuerdos se alcanza antes de que ninguna de las partes presente una solicitud de desestimación.

Por qué esto es importante desde el punto de vista operativo

Dado que los casos se resuelven rápidamente, no existe una jurisprudencia vinculante que aclare qué se entiende por «pago accesible» con el nivel de detalle que esperaría un ingeniero sénior. En su lugar, la norma viene determinada por el conjunto de los acuerdos extrajudiciales, la mayoría de los cuales exigen el cumplimiento de las WCAG 2.1 AA, una auditoría anual y un plan de corrección. Las empresas están pagando por el cumplimiento de una norma que se establece en contratos privados, pero que nunca ha sido objeto de resolución judicial en sentencias publicadas.

El modelo de volumen: diez demandantes, 1.289 casos

La cifra principal —8.788 casos— resulta engañosa si no se desglosa más a fondo. La parte demandante de la lista de causas está muy concentrada. Los diez demandantes más activos de la base de datos, en conjunto, representan el 14,7 % de todas las demandas presentadas. El demandante individual más prolífico presentó 256 demandas distintas.

Fig. 5 Los 10 demandantes principales por volumen de casos federales (anonimizados)
#Demandante (anonimizado)Casos% del total
01Demandante A: el demandante que más demandas ha presentado en la base de datos
2562.91%
02Demandante B
2072.36%
03Demandante C
1581.80%
04Demandante D
1311.49%
05Demandante E
1211.38%
06Demandante F
1151.31%
07Demandante G
991.13%
08Demandante H
971.10%
09Demandante I
941.07%
10Demandante J
860.98%

Se han ocultado los nombres de los demandantes; las cifras se han obtenido a partir de los metadatos de PACER. De un total de 8.788 demandas, los diez principales demandantes interpusieron 1.289 casos en conjunto (14,66 %). El demandante individual más destacado figura como parte demandante en casi 1 de cada 35 casos del conjunto de datos.

Esta concentración no es señal de mala fe: muchos de estos demandantes padecen discapacidades legítimas y documentadas, y se han enfrentado personalmente a las barreras que describen en sus demandas. Pero sí es señal de que los demandados que pierden en los tribunales rara vez pierden ante un desconocido. Se repiten los mismos nombres, a menudo representados por los mismos bufetes, que suelen presentar demandas basadas en plantillas casi idénticas. La estructura del litigio premia la eficiencia por parte de los demandantes y la capitulación por parte de los demandados. No premia los argumentos novedosos por ninguna de las dos partes.

La matriz de triaje

Si la pregunta es «¿qué debo solucionar primero?», la respuesta depende de dos factores: la frecuencia con la que se menciona un obstáculo concreto (frecuencia) y el grado en que bloquea directamente una transacción (gravedad). La matriz que se muestra a continuación combina ambos aspectos. Las celdas están coloreadas según el volumen relativo de menciones en nuestro corpus de 4.050 transacciones de pago, y las celdas más oscuras representan los modos de fallo que más merecen ser abordados en un sprint.

Fig. 6 Matriz de fallos × etapa (densidad de citas)
Patrón de fallo Añadir al carrito Carrito Dirección Pago Confirmación
Estado no anunciado Alto Alto Med Med Alto
Campos sin etiquetar Bajo Alto Alto
Errores no señalados Bajo Med Alto Alto Med
Pérdida de modo / foco Alto Alto Med Med Med
Fallo del teclado Med Med Bajo Alto Bajo
Reentrada forzada en caso de error Bajo Med Med
Inaccesibilidad del CAPTCHA Bajo Med
No se cita con frecuencia Bajo Medio Alto Muy alto

Hay dos casos que merecen una mención especial. «Estado no indicado × Añadir al carrito» es el obstáculo más citado en todo el conjunto de datos; si no se puede solucionar nada más, hay que solucionar esto. «Campos sin etiquetar × Pago» es el clásico caso de incumplimiento normativo: un formulario de tarjeta de crédito con campos que se indican como vacíos es una infracción indiscutible.

¿Cuánto te cuesta esto hoy, antes de que se presente ninguna demanda?

El riesgo de litigios es uno de los costes que conlleva un proceso de pago inaccesible. El otro —normalmente mayor y siempre presente— son los pedidos que nunca se completan porque el comprador no ha podido rellenar el formulario. La calculadora que aparece a continuación utiliza tres parámetros que puedes modificar para estimar ese coste en tu propio embudo de ventas. Los valores predeterminados son conservadores y se basan en referencias de distintos sectores; ajústalos para que se adapten a tu negocio.

Modelo de exposición de «Inaccessible-checkout»

Todos los campos de entrada son controles deslizantes. Las cifras se actualizan en tiempo real a medida que los ajustas. Nada de esto es una estimación: se trata de un modelo aproximado destinado a servir de base para uno más riguroso.

Pedidos mensuales bloqueados
650
los usuarios de lectores de pantalla o de teclado que dejan de utilizar
Ingresos mensuales no percibidos
$78,000
en el AOV que has facilitado
Ingresos anualizados en riesgo
$936,000
proyección lineal, sin hipótesis de crecimiento

Metodología. Según las estimaciones de WebAIM y BOIA, el uso activo de lectores de pantalla se sitúa aproximadamente entre el 1 % y el 3 % de los visitantes de sitios web en EE. UU.; si se incluye a un grupo más amplio de usuarios que utilizan únicamente el teclado o que padecen discapacidades motoras, la cifra aumenta. La tasa de bloqueo del 65 % es el extremo superior de la medición de WebAIM Million para 2024 sobre la frecuencia con la que un escaneo de la página de inicio detecta al menos una barrera de bloqueo (95,9 %); las barreras en el proceso de pago suelen tener un alcance más limitado. Utilice sus propios datos cuando los tenga. Este modelo excluye el riesgo de litigios, el coste para la marca y el valor de los clientes perdidos de forma permanente tras un proceso de pago fallido, factores que agravan las cifras mostradas.

En cambio, así es como se ve un proceso de pago accesible

La tabla comparativa que figura a continuación empareja los modos de fallo más citados en el conjunto de datos con el patrón de ingeniería que resuelve cada uno de ellos. Ninguno de los patrones de la columna de la derecha es especulativo: todos ellos son técnicas documentadas de WCAG 2.2 Nivel AA.

Contra quién presentaron la demanda los demandantes

  • Aparece visualmente el mensaje «Añadir al carrito» sin role="status" región; no se ha informado sobre la tecnología de apoyo
  • El campo de entrada CVC solo contiene texto de marcador de posición; no hay código de programación <label>
  • Se abre la ventana modal de confirmación de la dirección, pero el foco permanece en el botón «Continuar» anterior
  • La validación en línea aparece en rojo debajo del campo; el lector de pantalla no la lee en voz alta
  • Botones de PayPal / Apple Pay representados como <div> con un controlador de clics; sin detector de eventos de teclado
  • Si el envío falla, la página se actualiza y el formulario se borra; el usuario debe volver a empezar desde el nombre y el correo electrónico

Qué hace un proceso de pago accesible

  • Se ha anunciado «Artículo añadido» a través de aria-live="polite" región o role="status"
  • Cada entrada envuelta en un elemento asociado mediante programación <label> – «placeholder» no es una etiqueta
  • Se abre la ventana modal, el foco se desplaza al encabezado del cuadro de diálogo, el foco queda bloqueado, al pulsar ESC se recupera el foco anterior
  • Errores notificados a través de aria-describedby y el campo recibe aria-invalid="true"
  • Los botones de pago son reales <button> elementos con un contorno de foco visible ≥ 2 píxeles
  • Los errores se muestran directamente en la página; los campos que antes eran válidos siguen rellenados; no se reinicia toda la página

Lista de verificación de trece pasos para la corrección

A partir de los patrones de densidad de citas observados en el conjunto de datos, los elementos que figuran a continuación se han ordenado de mayor a menor según la frecuencia con la que aparecen en los escritos presentados en la fase de resolución. Al ir de arriba abajo por esta lista, se abordan la gran mayoría de las alegaciones que se plantearán en una demanda presentada por un demandante reincidente.

Medidas correctivas para reducir el riesgo de litigios, ordenadas por frecuencia de citación

  1. Anunciar el estado de «Añadir al carrito». Añadir un elemento oculto visualmente role="status" región de ejecución; muestra el mensaje «Artículo añadido – N artículos en el carrito» cada vez que se añada un artículo correctamente.
  2. Asigna una etiqueta a cada campo de entrada mediante programación. Comprueba tu código con un análisis de Axe-Core o WAVE; resuelve todos los label-missing Regla. Los marcadores de posición nunca son etiquetas.
  3. Notificar errores en cupones y promociones. Error de empate <span> elementos a la entrada a través de aria-describedby; añadir aria-invalid="true" en caso de validación fallida.
  4. Coloca el foco en las ventanas modales. Cuando se abra un cuadro de diálogo de confirmación, coloca el foco en el título o en el primer elemento interactivo. Al cerrarlo, devuelve el foco al elemento que lo activó.
  5. Fijar el foco en las ventanas modales activas. En un cuadro de diálogo abierto, las teclas Tab y Mayús+Tab permiten desplazarse por el cuadro de diálogo; la tecla Esc lo cierra.
  6. Convierte los botones de pago en botones reales. Sustituye cualquier <div onclick> envoltorios para PayPal, Apple Pay, Google Pay y «Realizar pedido» con <button> elementos. Añadir estilos de foco visibles ≥ 2 píxeles.
  7. Marca los campos obligatorios de forma semántica. Añadir aria-required="true" y un indicador visible de «Obligatorio». Agrupa los campos obligatorios relacionados con <fieldset>.
  8. Conservar el estado del formulario si falla la validación. Los errores no deben borrar los campos que se hayan rellenado correctamente. Volver al modo de edición; situar el foco en el primer campo de entrada no válido.
  9. Anuncia los estados en los que ha tenido éxito. Los campos «Pedido realizado» y «Descuento aplicado» deben transmitirse a la tecnología de asistencia a través del mismo role="status" mecanismo de «Añadir al carrito».
  10. Utiliza un CAPTCHA accesible. Si no tienes más remedio que utilizar uno, lo mínimo es contar con una alternativa de audio y el modo de accesibilidad de reCAPTCHA. Mejor aún: sustitúyelo por una verificación invisible o basada en el comportamiento.
  11. Haz que los indicadores de paso sean significativos. Si tu proceso de pago consta de varios pasos, muéstralos como un <nav aria-label="Checkout progress"> con un <ol> y aria-current="step".
  12. Prueba el proceso con un lector de pantalla real. Realiza el proceso de pago completo de principio a fin con NVDA + Firefox o VoiceOver + Safari. Los análisis automatizados pasan por alto aproximadamente la mitad de las barreras con las que se encontrarán tus usuarios.
  13. Soluciona el problema a nivel del sistema de diseño. La mayoría de los errores en las páginas de pago se deben a componentes compartidos (Modal, Input, Toast). Si se corrige el componente una sola vez, la corrección se aplica a todas las páginas de pago que lo utilizan; sin embargo, si se corrige la página una sola vez, esto no ocurre.
Un modelo que vale la pena interiorizar

Las barreras en la fase de pago del conjunto de datos se agrupan en cinco componentes: la ventana emergente, el modal, el campo de entrada, el mensaje de error y el botón de envío. Si esos cinco componentes se prueban con un lector de pantalla, de forma aislada, antes de que lleguen a la fase de pago, el conjunto de reclamaciones del corpus se reduce a una pequeña minoría. La clave está en el nivel del sistema de diseño. El litigio, por desgracia, se sitúa a nivel de la página, y llega por correo certificado.

Conclusión: la cuestión técnica, reformulada

La tesis de este artículo —que el proceso de pago es la parte más litigada de Internet— no se basa en el volumen de demandas presentadas, aunque este sea llamativo. Se basa en la estructura del recorrido del usuario. De todas las áreas de un sitio web comercial, el proceso de pago es aquella cuyo fallo se ajusta con mayor precisión a la definición legal de denegación de servicio, aquella cuyos daños se traducen más claramente en una reclamación y aquella cuyos errores son más recurrentes entre los demandados. Ninguno de esos hechos cambiará en 2027. Lo que sí puede cambiar es la decisión de ingeniería que los provoca.

Las 4.050 incidencias que recoge este artículo no resultan, al analizarlas, nada misteriosas. Se trata de los mismos cinco o seis fallos que se producen en los mismos cinco o seis componentes. La solución más eficaz que puede aplicar un minorista no se encuentra en la página de pago, sino en el sistema de diseño que la genera. Corregí el mensaje emergente, el modal, el campo de entrada, el mensaje de error y el botón de enviar —una sola vez, en la biblioteca de componentes— y el conjunto de datos que sustenta este artículo se reducirá en algo así como un orden de magnitud. Los demandantes pasarán a otro frente. Tus clientes, no.

ARCHIVADO · ANALIZADO · ARCHIVADO DE NUEVO

Fuentes y metodología

Los metadatos de los casos civiles federales se han extraído de PACER (Acceso Público a los Registros Electrónicos de los Tribunales) y abarcan 8.788 casos relacionados con la accesibilidad web presentados ante los tribunales de distrito de EE. UU. entre enero de 2007 y abril de 2026, identificados mediante los códigos de reclamación del Título III de la ADA y el filtrado de cadenas de búsqueda con el término «sitio web». Se realiza un análisis a nivel de tema a partir de una extracción mediante OCR y PLN de los mismos expedientes, lo que da como resultado 81 509 menciones distintas de problemas de accesibilidad clasificadas en 28 taxonomías superficiales.

Las referencias a las WCAG se refieren a las WCAG 2.1 (la norma más citada en los acuerdos extrajudiciales del sector privado en EE. UU.) y a las WCAG 2.2 (la última recomendación publicada en octubre de 2023, ratificada en diciembre de 2024). Cuando los documentos citan la EAA, la norma EN 301 549 o la Norma Definitiva del Título II del Departamento de Justicia (abril de 2024), los criterios se normalizan a su equivalente en WCAG 2.1 AA.

Los nombres de los demandantes se han ocultado en este artículo. Todos los demandantes son personas reales y sus casos figuran en los registros públicos de PACER. El patrón de agregación se presenta con fines analíticos; cualquier lector que desee verificar una presentación concreta puede consultar públicamente las entradas originales del expediente.

La calculadora de exposición del apartado 11 tiene carácter ilustrativo. Las encuestas a usuarios de lectores de pantalla de WebAIM (2014-2024) y la auditoría anual de páginas de inicio de WebAIM Million constituyen las principales referencias del sector para estimar la cuota de visitantes y la frecuencia de las barreras. Adapta los valores predeterminados de la calculadora a tus propios datos analíticos, si dispones de ellos.

Referencia: AIOPSGROUP Accessibility Intelligence (2026). El proceso de pago en el comercio electrónico: el ámbito más litigado de Internet. Número 04:12.