Checkout online accesible: una prueba práctica para pequeños negocios

Una venta puede perderse antes de que falle el pago: una persona quizá no pueda elegir una opción, entender un error del formulario o llegar a la confirmación. Por eso la accesibilidad no es solo una cuestión estética. Para una tienda, taller o negocio que acepta reservas, forma parte del servicio completo.

La Directiva Europea de Accesibilidad ofrece el marco común de la UE para determinados servicios de comercio electrónico. La aplicación nacional, el alcance y las excepciones deben comprobarse en cada país y actividad. En España, conviene contrastar antes de publicar afirmaciones jurídicas las normas nacionales de transposición y de control aplicables. Este artículo aporta una rutina operativa, no asesoramiento legal.

Pruebe el recorrido completo, no solo la portada

Plantee una tarea real: encontrar un servicio o producto, seleccionar una opción obligatoria, introducir datos, revisar el importe y obtener la confirmación. No basta con que el contenido se vea; la persona debe poder terminar sin adivinar.

Una revisión de 25 minutos antes de publicar

1. Empiece en la página principal usando solo Tab, Mayús+Tab, Intro y Espacio.
2. Encuentre una oferta, seleccione todas las opciones obligatorias y añádala.
3. Cambie una cantidad y elimine un artículo.
4. Envíe primero datos incorrectos a propósito.
5. Corrija los errores sin ratón. El mensaje debe explicar qué ocurre y cómo resolverlo.
6. Abra y cierre ventanas, consentimiento de cookies y opciones de pago; el foco debe avanzar y volver de forma previsible.
7. Revise la confirmación con ventana estrecha y zoom del navegador.
8. Anote navegador, dispositivo, fecha, recorrido y bloqueo; no solo aprobado/no aprobado.

Las comprobaciones automáticas detectan fallos técnicos repetibles, pero no prueban que el proceso sea comprensible. Mantenga una prueba manual con teclado y, cuando sea posible, reciba feedback de personas que usan ayudas técnicas distintas.

Base técnica útil, sin promesas excesivas

Las WCAG 2.2 dan un lenguaje común: perceptible, operable, comprensible y robusto. No sustituyen por sí solas una evaluación jurídica. En la práctica ayudan estas decisiones:

• priorizar HTML semántico antes que ARIA: botones, etiquetas, encabezados y listas reales;
• foco visible y orden lógico de foco;
• errores junto al campo y resumen con enlaces a los campos inválidos;
• cambios de total, disponibilidad y resultado comunicados sin depender solo de color o movimiento;
• idioma de la página y cambios reales de idioma bien marcados;
• una vía de atención sencilla si el proceso digital se bloquea.

Los servicios externos también forman parte del recorrido

El pago, la agenda, el aviso de cookies, los mapas o el chat pueden pertenecer a otro proveedor, pero afectan a su cliente. Mantenga una ficha breve por servicio: finalidad, páginas donde aparece, responsable, versión o configuración, limitación conocida, contacto y alternativa.

Al contratar o renovar, solicite evidencia fechada, incidencias conocidas, pruebas de teclado y lector de pantalla, un canal de escalado y confirmación de que el estilo propio no rompe opciones accesibles. La declaración de un proveedor no sustituye la prueba de su configuración.

La accesibilidad se vuelve gestionable cuando se trata como control de calidad: probar un recorrido pequeño, registrar el resultado y repetir tras cada cambio.