La accesibilidad de la banca digital y la EAA

Por qué la banca y la accesibilidad chocan tan mal

La banca está pensada para proteger a las personas. Gestionar tu dinero —consultar saldos, hacer pagos, solicitar préstamos, revisar extractos— es una parte fundamental de la vida financiera moderna. Cuando las plataformas de banca digital son inaccesibles, las personas con más probabilidades de quedar excluidas suelen ser precisamente las que tienen menos alternativas.

Clientes mayores con pérdida de visión asociada a la edad que dependen de lectores de pantalla. Personas con discapacidades motoras que no pueden usar un ratón. Clientes sordos que no pueden recurrir a la atención telefónica y necesitan realizarlo todo en línea. Son usuarios reales, presentes en la base de clientes de cualquier banco, y la European Accessibility Act convierte ahora su acceso en un requisito legal.

La banca y los servicios financieros están explícitamente nombrados en el alcance de la EAA. El plazo del 28 de junio de 2025 se aplicó a los servicios financieros igual que al comercio electrónico y a las telecomunicaciones. Para los bancos, esto no es opcional.

Los fallos de accesibilidad más habituales en la banca

Inicio de sesión y autenticación inaccesibles

Los flujos de inicio de sesión son la puerta de entrada a todos los servicios bancarios, y con frecuencia presentan problemas de accesibilidad:

• CAPTCHA sin alternativa de audio, lo que impide a los usuarios ciegos superar la autenticación
• Flujos de contraseña de un solo uso (OTP) que dependen del SMS: algunos usuarios con discapacidad cognitiva tienen dificultades para gestionar una autenticación de varios pasos bajo presión de tiempo
• Expiraciones de sesión que no avisan al usuario antes de finalizar la sesión y que no se pueden prorrogar: los usuarios que necesitan más tiempo para completar las tareas (entre los que se incluyen muchos usuarios con discapacidad) se ven expulsados de la sesión una y otra vez

La WCAG 2.1 2.2.1 Tiempo Ajustable (Nivel A) exige que los límites de tiempo de sesión sean ajustables o prorrogables.

Campos de formulario sin etiquetar e inaccesibles

La banca implica muchos formularios: transferencias de fondos, configuración de pagos, cambios de domicilio, solicitudes de préstamos. Los mismos fallos de accesibilidad en formularios que afectan a cualquier sitio web resultan especialmente costosos en la banca: un usuario ciego que no puede completar un formulario de pago no puede acceder a un servicio bancario esencial.

El fallo más habitual: campos de formulario sin elementos <label> correctamente asociados. Sin una etiqueta, los lectores de pantalla anuncian «editar texto, en blanco» y el usuario no sabe qué debe introducir. Lo tratamos en detalle en nuestra guía sobre mensajes de error accesibles y se aplica por igual a los campos de formulario estándar.

Extractos y documentos PDF inaccesibles

Extractos mensuales, términos y condiciones, contratos de préstamo, documentos de información de productos: los bancos generan enormes volúmenes de contenido en PDF, y casi todo procede de sistemas que producen PDF inaccesibles.

Un PDF accesible tiene una estructura etiquetada, un orden de lectura lógico, niveles de encabezado significativos y texto alternativo para cualquier imagen que contenga información. Un PDF exportado desde un documento de Word o generado por un motor de informes sin procesamiento de accesibilidad no suele tener nada de esto. Para saber más, consulta nuestra guía de accesibilidad de PDF.

Navegación por teclado deficiente en los flujos de transacción

Transferir fondos, dar de alta a un beneficiario, consultar el historial de transacciones: los flujos complejos de varios pasos habituales en la banca a menudo contienen componentes que solo funcionan con el ratón: menús desplegables que no responden a la entrada por teclado, selectores de fecha sin soporte para teclado, cuadros de diálogo de confirmación que atrapan el foco del teclado.

Aplicaciones móviles inaccesibles

La EAA cubre tanto las aplicaciones móviles como los sitios web. Las apps bancarias, en particular, suelen tener componentes nativos que se comportan de forma distinta a los elementos web, con capas de accesibilidad que requieren un trabajo explícito para implementarse correctamente.

Entre los fallos habituales de la banca móvil se incluyen: elementos interactivos demasiado pequeños para tocarlos de forma fiable (la WCAG 2.5.5 Tamaño del Objetivo, Nivel AAA, sugiere un mínimo de 44×44 píxeles CSS), contraste insuficiente en temas de interfaz personalizados, y barras de pestañas o patrones de navegación personalizados que no exponen su estado a las API de accesibilidad.

Contraste insuficiente en el diseño de la interfaz

El diseño de la interfaz bancaria tiende a menudo al minimalismo y al uso de gris claro sobre blanco para la información secundaria: números de cuenta, referencias de transacciones, texto de apoyo. Esto suele incumplir la WCAG 1.4.3 Contraste Mínimo (Nivel AA), que exige una relación de 4,5:1 para el texto normal.

El coste de la inaccesibilidad para la confianza

La banca es una relación de confianza. Cuando un usuario con discapacidad no puede acceder a sus extractos de cuenta, no puede domiciliar un recibo de forma independiente o se ve obligado a llamar a una línea telefónica (que puede tener sus propias barreras de accesibilidad) para completar tareas que sus pares sin discapacidad hacen en línea, el mensaje es claro: este servicio no se diseñó para ti.

El coste reputacional de ese mensaje, en un sector donde la confianza del cliente es fundamental, es significativo. El coste legal bajo la EAA es cada vez más tangible. Y el coste práctico —los clientes que en silencio se pasan a un competidor que sí funciona con su tecnología de asistencia— es más difícil de medir, pero muy real.

Por dónde empezar

La EAA exige un estándar WCAG 2.1 Nivel AA en todos tus servicios digitales. Para la mayoría de los bancos, alcanzarlo en todos los puntos de contacto digitales de forma simultánea no es factible: hay demasiada superficie. Prioriza según el impacto en el cliente:

Máxima prioridad:

1. Flujos de inicio de sesión y autenticación: si los clientes no pueden entrar, nada más importa
2. Gestión básica de la cuenta: consultar saldo, consultar transacciones, transferir fondos
3. Descarga de extractos y documentos PDF

Segunda prioridad:

1. Configuración y gestión de pagos
2. Flujos de solicitud de préstamos y productos
3. Flujos principales de la app móvil (siguiendo las prioridades de la web)

Para cada área, ejecuta tanto un análisis automatizado (que detecta problemas de contraste, etiquetado y estructura) como pruebas manuales con tecnología de asistencia (que detectan fallos de navegación por teclado, problemas de gestión del foco y errores en los anuncios del lector de pantalla).

Ejecuta un análisis gratuito de tu sitio web bancario público para ver dónde te encuentras actualmente en cuanto a los problemas automatizables. Para una revisión exhaustiva de los flujos bancarios autenticados —donde reside la mayoría de los fallos de accesibilidad complejos—, habla con nuestro equipo sobre un programa de auditoría estructurado.