La autenticación accesible deja de ser un asunto solo de accesibilidad y pasa a tocar el diseño de cualquier área de clientes que tenga un despacho de abogados. Desde 2023, el estándar WCAG 2.2 incluye un criterio concreto para el proceso de inicio de sesión: ningún paso puede exigir memorizar, transcribir o resolver algo sin ofrecer una alternativa. Afecta al login del panel de clientes, a la recuperación de contraseña y a cualquier formulario de verificación que tu web use para identificar a quien entra. Quien diseña ese acceso sin mirar el criterio corre el riesgo de perder exactamente al cliente que ya había decidido confiar en el despacho.
La autenticación accesible, según el criterio WCAG 2.2 3.3.8, exige que ningún paso de inicio de sesión obligue a memorizar una contraseña, transcribir un código o resolver un acertijo visual sin ofrecer una alternativa como pegar el dato o usar un gestor de contraseñas. Es de nivel AA y aplica desde 2023.
Qué exige la autenticación accesible en la WCAG 2.2
El criterio 3.3.8, Accessible Authentication (Minimum), es de nivel AA y forma parte de la actualización WCAG 2.2 publicada por el W3C. Dice, en esencia, que ningún paso del inicio de sesión puede depender de lo que la norma llama un «test de función cognitiva»: memorizar una contraseña exacta, transcribir un código a mano, resolver un acertijo visual o deletrear algo sin fallos. Si tu web pide cualquiera de esas cosas sin dar otra vía, el criterio no se cumple.
No es un capricho técnico aislado: viene de la misma familia que el texto alternativo en imágenes, otro criterio que obliga a dar una alternativa perceptible a quien no puede procesar la información del modo estándar. En autenticación, la alternativa no es un texto: es permitir pegar, usar un gestor de contraseñas o reconocer algo que el propio usuario ya aportó.
Un «test de función cognitiva», en este criterio, es cualquier paso de login que obligue a recordar, transcribir, calcular o deletrear sin ayuda: ahí es donde falla la autenticación accesible.
Qué cuenta como test cognitivo para la WCAG
La norma pone ejemplos concretos de lo que SÍ cuenta como test cognitivo: una contraseña que hay que recordar carácter a carácter, un código de verificación que el usuario tiene que copiar a mano desde el SMS, un CAPTCHA matemático o una pregunta de seguridad («el nombre de tu primera mascota») que exige memoria a largo plazo. En cambio, pedir el nombre, el email o el teléfono NO cuenta como test cognitivo: son identificadores personales que cualquier persona usa igual en cualquier web, y por eso quedan fuera de la restricción.
Cuatro vías para cumplir el criterio
El propio criterio da cuatro salidas, y basta con ofrecer una para cumplir. Ninguna obliga a tirar el sistema de usuario y contraseña que ya tiene tu web:
- Otro método de autenticación que no dependa de memoria, como un enlace de acceso enviado por correo.
- Un mecanismo de ayuda: dejar que el navegador o el gestor de contraseñas rellene el campo, y no bloquear el pegado de la contraseña ni del código de verificación.
- Reconocimiento de objetos, como identificar una imagen genérica (un coche, un animal) en lugar de transcribir texto.
- Contenido no textual aportado por el propio usuario, como reconocer una foto que él mismo subió al crear la cuenta.
En la práctica, la salida que resuelve la mayoría de los casos de un despacho es la segunda: permitir pegar y dejar actuar al gestor de contraseñas. Es la que menos desarrollo exige y la que más fricción quita, porque no cambia el diseño del formulario.
Por qué bloquear el pegado de contraseñas incumple el criterio
Algunos formularios siguen desactivando el pegado en el campo de contraseña, pensando que así evitan errores. Es justo el fallo que señala el criterio: obliga a transcribir de memoria o carácter a carácter, que es un test cognitivo en toda regla. El coste no es solo de accesibilidad. El Baymard Institute midió hasta un 18,75% de abandono en el proceso de pago cuando el usuario tenía que recuperar una contraseña olvidada por culpa de un login con fricción. Un área de clientes que no deja pegar la contraseña empuja a ese mismo abandono, solo que con un cliente que ya pagaba.
Cuándo la ley obliga a tu despacho a cumplirlo
La WCAG 2.2 no es, por sí sola, una ley española. Pero desde el 28 de junio de 2025 hay una que sí lo es y que recoge este criterio en la práctica: la Ley 11/2023, que traspone la directiva europea de accesibilidad. Su Anexo I obliga a que los servicios de comercio electrónico ofrezcan métodos de identificación, firma electrónica y pago «perceptibles, funcionales, comprensibles y resistentes»: la misma exigencia que la autenticación accesible, con otras palabras.
Esto no afecta a cualquier despacho: afecta al que vende por internet, con cobro y acceso de cliente incluidos, como ya pasa cuando se ofrecen servicios legales con venta online. Para el resto, la obligación legal general ya existe por otra vía, que repasamos en qué despachos obliga ya la ley de accesibilidad. Aquí el matiz es distinto: no es que la web deba ser accesible en general, es que el paso de entrar y pagar no puede exigir memoria ni transcripción sin alternativa.
El área de clientes y el login accesible
Cada vez más despachos añaden una zona privada donde el cliente sigue su expediente, descarga escritos o revisa facturas. Ahí es donde más se nota si el login está bien pensado: un cliente que ya está nervioso por su caso no necesita además pelearse con una contraseña que su gestor no puede rellenar.
Conviene no confundir esto con el acceso de gestión del propio WordPress, donde el doble factor de autenticación sí es recomendable y no choca con el criterio: un código de un solo uso cumple si se puede pegar o si llega por notificación en el móvil, sin obligar a copiarlo a mano. La autenticación accesible no prohíbe capas de seguridad adicionales: prohíbe que esas capas dependan de memoria o transcripción sin alternativa.
Qué pasa con el código de verificación en dos pasos
Un código de un solo uso por SMS o email no incumple el criterio por sí mismo: lo que lo incumple es obligar a leerlo en una pantalla y teclearlo de memoria en otra. La mayoría de navegadores móviles ya autocompletan ese campo si el formulario está bien marcado, y basta con no bloquear el pegado para que la alternativa exista. Un despacho que active la verificación en dos pasos para su área de clientes debe probar, antes de publicarla, que el código se puede pegar desde el gestor de notificaciones del móvil sin transcribirlo a mano.
Preguntas frecuentes sobre autenticación accesible
¿La autenticación accesible obliga a quitar la contraseña?
No. Obliga a que, si hay contraseña, el usuario pueda pegarla o dejar que un gestor la rellene en vez de teclearla de memoria. Quitar la contraseña es una opción, no una obligación: el criterio se cumple igual con un login clásico que permita pegar el dato.
¿Un CAPTCHA incumple la autenticación accesible?
Un CAPTCHA que pida resolver un cálculo o leer texto distorsionado sí incumple, salvo que ofrezca una alternativa de reconocimiento de objetos. Los que piden marcar una casilla o identificar fotos genéricas, como coches o semáforos, entran dentro de las excepciones que admite el criterio.
¿Desde cuándo es obligatorio este criterio?
El criterio 3.3.8 forma parte de la WCAG 2.2, publicada en octubre de 2023. No es una ley por sí mismo, pero coincide con lo que exige desde el 28 de junio de 2025 la Ley 11/2023 para el comercio electrónico, incluida la venta de servicios legales online.
Fuente: W3C – WCAG 2.2, Understanding Accessible Authentication (Minimum)
