El proceso de pago es para muchas tiendas en línea la parte más vulnerable del sitio en lo que respecta a la accesibilidad. Aunque las páginas de productos suelen funcionar razonablemente bien con un lector de pantalla, el proceso se atasca en cuanto un cliente debe pagar: botones sin etiqueta clara, mensajes de error que no se anuncian, o un widget de pago de un proveedor externo que no se puede utilizar sin ratón. Esto no es una coincidencia. El proceso de pago contiene la mayoría de elementos dinámicos de todo el sitio, y los elementos dinámicos son precisamente donde los lectores de pantalla y la navegación por teclado se atascan más rápidamente.
Esto no es un detalle menor. El paso de pago está sujeto a los mismos requisitos EN 301 549 que el resto del sitio, y un usuario recorre este paso por definición en el momento en que realmente quiere comprar algo. Un lector de pantalla que se atasca ahí excluye a un cliente en el momento decisivo. Esta es también la razón por la que en axessia incluimos el paso de pago de forma estándar en el escaneo completo, y no solo en el escaneo rápido gratuito de las páginas principales.
Dónde falla en la práctica
Los problemas más comunes son notablemente recurrentes. Un botón para "siguiente paso" o "pagar ahora" que contiene solo un icono sin texto que un lector de pantalla pueda leer. Un mensaje de error en un campo de código postal mal rellenado que aparece en pantalla, pero no se anuncia porque falta el acoplamiento técnico correcto. Un indicador de progreso ("paso 2 de 3") que es visualmente claro pero permanece invisible para un lector de pantalla. Y el propio proveedor de pagos: los widgets de iDEAL o tarjeta de crédito de terceros a menudo se integran de forma independiente y tienen su propio nivel de accesibilidad, sobre el cual una tienda en línea tiene poco control pero sigue siendo responsable.
El orden de enfoque también es un problema recurrente. Después de enviar un formulario con un error, la atención del usuario debe dirigirse al mensaje de error. Si esto no ocurre, alguien que trabaja con el teclado o un lector de pantalla sigue buscando qué salió mal, sin ninguna pista.
Por qué un escaneo automatizado detecta esto parcialmente
Un escaneo automatizado es bueno detectando etiquetas faltantes, botones vacíos y problemas estructurales en el código fuente. Lo que un escaneo no puede evaluar bien es el comportamiento: si un mensaje de error se anuncia realmente en voz alta, si el enfoque salta lógicamente, y si el paso de pago sigue siendo accesible sin ratón después de completar los datos. Esto requiere que alguien realmente recorra el paso con un lector de pantalla. Esta es precisamente la limitación que se menciona explícitamente en cada informe de axessia: un escaneo evalúa parte de los requisitos, no todo.
Por eso el escaneo completo no solo se enfoca en la página de inicio, sino especialmente en los pasos que un cliente realmente realiza, incluido el inicio de sesión y el pago. Si primero desea una indicación sin obligaciones, puede ver en unas pocas preguntas dónde se encuentra su sitio en este momento.
Qué significa esto para los requisitos que debe cumplir
La norma subyacente, EN 301 549, se traduce en la práctica en WCAG 2.1 nivel AA. Contiene requisitos sobre el nombre, función y estado de los elementos interactivos, sobre mensajes de estado que deben ser perceptibles incluso sin atención visual, e información que no se comunica únicamente mediante color o posición. Para la formulación exacta y la ubicación en el texto oficial, EUR-Lex es la fuente apropiada; traducimos esos requisitos a situaciones reconocibles como el proceso de pago, pero no hacemos ninguna declaración sobre su situación específica. Puede leer más contexto sobre cómo se realiza esta traducción en la página que explica de dónde proviene nuestra información.
Cómo probar esto usted mismo o hacerlo probar
Un primer paso práctico es recorrer el proceso de pago sin ratón: solo con la tecla Tab e Intro. Si no puede avanzar en algún momento, es probable que un lector de pantalla también se quede atascado allí. Un segundo paso es hacer pruebas con un lector de pantalla gratuito como NVDA, y prestar especial atención a lo que se lee en voz alta cuando se produce un error. Para obtener una imagen completa, incluidas las partes que solo se descubren mediante un recorrido manual, es necesaria una prueba más exhaustiva; axessia realiza esa prueba y documenta los hallazgos en una lista de tareas priorizada, pero no realiza ningún trabajo de reparación. Eso depende de su propio desarrollador o proveedor, a menudo basándose exactamente en los puntos que mencionamos. Otros temas frecuentes sobre este tipo de problemas concretos los encontrará recopilados en la base de conocimientos con temas desarrollados por situación.
Si desea saber cuánto cuesta una prueba completa de su proceso de pago e entorno de inicio de sesión, encontrará esa información de forma clara en la página con tarifas y lo que incluyen.
¿Desea hacerse una idea por su cuenta sin compromisos? El escaneo rápido gratuito de axessia le proporciona una primera impresión de sus páginas principales en cuestión de minutos, y la verificación de alcance le muestra si la normativa se aplica a su organización.