ComplyPages

Vea cómo es un hallazgo de ComplyPages

Nuestros informes están diseñados para la acción. Cada hallazgo explica dónde aparece la incidencia, por qué importa y qué puede hacer a continuación su desarrollador o agencia.

Estructura del informe

  1. Resumen ejecutivo
  2. Flujo revisado
  3. Principales riesgos de accesibilidad visibles
  4. Detalles de incidencias listos para desarrolladores
  5. Cola de correcciones sugerida
  6. Lista de comprobación de retest
  7. Recomendación de monitorización

1. Resumen ejecutivo

Este snapshot de ejemplo revisa un proceso de pago público e identifica riesgos de accesibilidad visibles que pueden afectar a la navegación por teclado, a la comprensión con lector de pantalla y a la cumplimentación de formularios. No es una evaluación legal ni una certificación, sino observaciones prácticas para ayudar a un equipo web a priorizar correcciones en un recorrido crítico para el cliente.

2. Flujo revisado

Snapshot de ejemplo para

example-store.com

Carrito → Pedido → Pago

Riesgo: Medio

Tipo de flujo

Proceso de pago de comercio electrónico

Páginas revisadas

4 páginas públicas

3. Principales riesgos de accesibilidad visibles

  • El botón de pedido no tiene nombre accesible (alta)
  • Un campo obligatorio no está etiquetado de forma programática (media)
  • El mensaje de error no se expone con claridad tras enviar el formulario (media)

4. Detalles de incidencias listos para desarrolladores

CP-0001

El botón de pedido no tiene nombre accesible

abiertoalta
Flow: Confirmación de pagohttps://example-store.com/checkout
Screenshot for CP-0001

Element: button.checkout-submit

WCAG 2.1 A 4.1.2WCAG 2.1 AA 2.4.6

EAA relevance: Preparación EAA — riesgo de accesibilidad visible en el proceso de pago público

Pasos de reproducción

  1. Abrir https://example-store.com/checkout con artículos en el carrito
  2. Inspeccionar el botón final con lector de pantalla o axe DevTools
  3. Observar la ausencia de nombre accesible en button.checkout-submit

Impacto en el cliente

Quienes usan lector de pantalla pueden no entender qué acción realiza el botón.

Impacto en el negocio

Si un cliente no identifica la acción final de pedido, puede quedar bloqueado sin completar la compra. Nota técnica: El botón se ve en pantalla, pero su nombre accesible falta o no es claro.

Corrección sugerida

Añadir un texto visible claro o un nombre accesible que describa la acción.

Ejemplo para copiar y pegar

Solo un ejemplo — adáptelo a su código.

<button class="checkout-submit" aria-label="Confirmar pedido">
  Confirmar pedido
</button>

Criterios de aceptación

  • Las tecnologías de apoyo anuncian el botón como «Confirmar pedido» o equivalente
  • El botón se puede alcanzar y activar con el teclado
CP-0002

Un campo obligatorio no está etiquetado de forma programática

abiertomedia
Flow: Formulario de datos del clientehttps://example-store.com/checkout

Element: input#customer-email

WCAG 2.1 A 1.3.1WCAG 2.1 A 3.3.2WCAG 2.1 A 4.1.2

EAA relevance: Preparación EAA — riesgo de accesibilidad visible en el proceso de pago público

Pasos de reproducción

  1. Abrir https://example-store.com/checkout
  2. Tabular hasta el campo de correo electrónico
  3. Confirmar que input#customer-email no tiene etiqueta asociada en el árbol de accesibilidad

Impacto en el cliente

Quienes usan tecnologías de apoyo pueden no saber qué información se solicita.

Impacto en el negocio

Una cumplimentación más difícil aumenta el abandono del pedido. Nota técnica: La etiqueta visible no está correctamente vinculada al campo de entrada.

Corrección sugerida

Asociar la etiqueta al campo mediante una relación for/id válida o un método de etiquetado accesible equivalente.

Ejemplo para copiar y pegar

Solo un ejemplo — adáptelo a su código.

<label for="customer-email">Correo electrónico</label>
<input id="customer-email" type="email" name="email" required />

Criterios de aceptación

  • Las tecnologías de apoyo anuncian correctamente la etiqueta del campo
  • El carácter obligatorio del campo queda claro
CP-0003

El mensaje de error no se expone con claridad tras enviar el formulario

abiertomedia
Flow: Validación del formulario de pedidohttps://example-store.com/checkout

Element: .field-error

WCAG 2.1 A 3.3.1WCAG 2.1 A 4.1.3

EAA relevance: Preparación EAA — riesgo de accesibilidad visible en el proceso de pago público

Pasos de reproducción

  1. Enviar el formulario de pedido con un correo electrónico no válido
  2. Observar que aparece el mensaje de error visual
  3. Confirmar que el error no se anuncia ni está vinculado al campo

Impacto en el cliente

Los usuarios pueden no entender por qué no pueden continuar.

Impacto en el negocio

Los errores de validación que no se anuncian impiden completar el pedido. Nota técnica: El mensaje de error aparece visualmente, pero puede no anunciarse ni vincularse al campo correspondiente.

Corrección sugerida

Vincular el mensaje de error al campo y asegurar que se anuncia cuando falla la validación.

Criterios de aceptación

  • Los usuarios identifican qué campo tiene el error
  • Los usuarios entienden el problema y pueden corregirlo sin pistas solo visuales

5. Cola de correcciones sugerida

Las incidencias se priorizan por gravedad e impacto en el cliente. Su desarrollador o agencia trabaja la cola en orden.

6. Lista de comprobación de retest

  • Repetir las comprobaciones de accesibilidad en /checkout tras desplegar las correcciones
  • Verificar con lector de pantalla que el botón de pedido tiene un nombre accesible
  • Confirmar que las etiquetas del formulario están asociadas a sus campos
  • Comprobar que los mensajes de error se anuncian cuando falla la validación

7. Recomendación de monitorización

Tras las primeras correcciones, considere la supervisión continua del recorrido de transacción para detectar regresiones en las fases de pedido y pago.