26 de octubre de 2026
Autenticación accesible y CAPTCHA: qué exige el criterio WCAG 3.3.8
Una autenticación accesible, según el criterio de conformidad 3.3.8 de las WCAG (nivel AA), es un inicio de sesión que no obliga a resolver, recordar ni transcribir nada. El texto del W3C es claro: no se debe exigir una prueba de función cognitiva, como recordar una contraseña o resolver un rompecabezas, en ningún paso del proceso de autenticación, salvo que ese paso ofrezca un método alternativo, un mecanismo de ayuda, o que la prueba consista en reconocer objetos o en identificar contenido no textual que el propio usuario aportó al sitio. En la práctica, un CAPTCHA de texto distorsionado o de cálculo, o un campo de contraseña que impide pegar, no cumplen si no existe otra vía de acceso. Un formulario de usuario y contraseña sigue siendo aceptable si deja que el navegador y los gestores de contraseñas rellenen los campos y acepta copiar y pegar, siempre que los demás pasos también cumplan el criterio. A continuación verá qué está prohibido, qué está permitido, cómo se tratan los códigos de verificación y qué alternativas al CAPTCHA presenta la nota «Inaccessibility of CAPTCHA» publicada en el sitio del W3C.
Qué dice el criterio 3.3.8 Autenticación accesible (mínima)
El objetivo que fija el W3C es permitir el inicio de sesión con menos esfuerzo mental. Algunas personas con discapacidad cognitiva no pueden resolver rompecabezas, memorizar un usuario y una contraseña ni volver a escribir códigos de un solo uso. El W3C considera expresamente que recordar una contraseña propia de un sitio es una prueba de función cognitiva, y recuerda que memorizar cadenas aleatorias de caracteres o un gesto que hay que realizar en una pantalla táctil excluye a algunas personas.
El criterio se centra en la autenticación de usuarios existentes. No cubre la creación de un nombre de usuario ni el alta de una cuenta, aunque las mismas técnicas (permitir pegar, no depender de la transcripción) también aligeran el registro. En cambio, recuperar o cambiar el correo y la contraseña forma parte de la autenticación: si el usuario debe aportar otra información para recuperar su cuenta, debe existir un método que no sea una prueba cognitiva.
- Alternativa: otro método de autenticación que no dependa de una prueba de función cognitiva.
- Mecanismo: algo ayuda al usuario a completar la prueba, por ejemplo la compatibilidad con gestores de contraseñas o copiar y pegar.
- Reconocimiento de objetos: la prueba consiste en reconocer objetos (imágenes, vídeo o audio).
- Contenido personal: la prueba consiste en identificar contenido no textual que el usuario aportó al sitio.
Autenticación accesible y CAPTCHA: lo que no está permitido
Todos los pasos cuentan. Con la autenticación multifactor, cada paso debe cumplir: tiene que haber un recorrido completo de autenticación que no dependa de pruebas cognitivas. El criterio también se aplica a los CAPTCHA y pruebas que solo aparecen en ciertas situaciones, por ejemplo con un bloqueador de anuncios o tras varios intentos fallidos de contraseña.
El W3C recoge el fallo F109: incumplimiento de los criterios 3.3.8 y 3.3.9 por impedir volver a introducir una contraseña o un código en el mismo formato. La página describe además casos concretos que obligan a transcribir o dependen de una prueba cognitiva, y que son un problema cuando no se ofrece otro método de autenticación sin prueba cognitiva:
- Un campo de contraseña que impide pegar y muestra un mensaje pidiendo escribirla a mano.
- Un script que impide al navegador o a un gestor de contraseñas rellenar los campos automáticamente.
- Una petición del tipo «introduzca el 1.º, 3.º y 5.º carácter de su contraseña», que obliga a transcribir.
- Un código de un solo uso de 6 dígitos repartido en 6 campos separados, donde pegar el código solo rellena el primer dígito.
- Un código de verificación que hay que transcribir a mano, sin poder pegarlo ni autocompletarlo.
- Un CAPTCHA de texto distorsionado: su alternativa de audio no sirve como «Alternativa» si el usuario tiene que transcribirla.
- Un CAPTCHA matemático o un rompecabezas visual, como girar el modelo 3D de una morsa hasta una dirección dada.
- Un contenido personal textual: no se beneficia de la excepción de contenido personal, porque depende del recuerdo en lugar del reconocimiento, y de la transcripción en lugar de la selección de un elemento.
Lo que sí está permitido: gestores de contraseñas, copiar y pegar y métodos sin prueba
El usuario (o correo) y la contraseña siguen siendo válidos si se deja que el navegador y los gestores de contraseñas de terceros rellenen los campos. Según el W3C, si el formulario cumple el criterio 1.3.5 (Input Purpose) y los controles tienen un nombre accesible adecuado según el 4.1.2 (Name, Role, Value), navegadores y gestores deberían poder reconocerlos y rellenarlos de forma fiable. Copiar y pegar también evita la transcripción: el usuario copia sus credenciales desde un gestor independiente y las pega en el formulario.
Entre las técnicas suficientes que enumera el W3C están la autenticación mediante enlace por correo (G218) y campos de correo y contraseña correctamente marcados (H100). Los ejemplos de la página incluyen además:
- WebAuthn, para autenticarse con el propio dispositivo (por ejemplo reconocimiento facial, huella o PIN, según lo que configure el usuario).
- El inicio de sesión con un proveedor externo mediante OAuth.
- Un doble factor con varias opciones, entre ellas un método USB en el que basta con pulsar un botón para introducir un token temporal.
- Un código QR escaneado con una aplicación del dispositivo del usuario.
- Una notificación enviada al dispositivo del usuario y confirmada con el mecanismo de autenticación de ese dispositivo.
CAPTCHA de reconocimiento de objetos y contenido personal
Un CAPTCHA que pide seleccionar todas las imágenes con un coche entra en la excepción de reconocimiento de objetos en el nivel AA. Un objeto es aquí una cosa material que se puede ver y tocar, incluidos vehículos y animales. Si la prueba va más allá del reconocimiento, por ejemplo multiplicar el número de gatos por el de perros, la excepción deja de aplicarse. Y una prueba basada en algo que fija el sitio, como recordar o transcribir una palabra, es una prueba de función cognitiva.
El contenido personal funciona así: al crear la cuenta, el usuario sube una imagen y, al iniciar sesión, la elige entre varias opciones. El W3C pide cuidar la seguridad, porque alguien no legítimo podría adivinar la imagen correcta. Sobre todo, recuerda que ambas excepciones no apoyan plenamente a las personas con necesidades de accesibilidad cognitiva y deberían evitarse si es posible: no se admiten en el criterio 3.3.9 Autenticación accesible (mejorada), de nivel AAA.
El W3C señala además que una opción para mostrar la contraseña puede mejorar las posibilidades de éxito de algunas personas cuando sigue siendo necesario escribir, por ejemplo al crear una contraseña que luego guardará un gestor.
Códigos de verificación y doble factor
Un servicio que exige transcribir a mano un código de verificación no es conforme. Como mínimo, debe poder pegarse el código (desde un gestor de contraseñas, una aplicación de mensajes SMS o una llave de seguridad por software) y el navegador debe poder rellenar el campo automáticamente.
Cuando el código llega a un segundo dispositivo, por ejemplo un SMS al móvil al iniciar sesión en un portátil, cómo se transfiere el código entre dispositivos queda fuera del alcance del criterio. En la evaluación se supone que el código está en el portapapeles y solo se comprueba que el campo acepta pegarlo. El W3C precisa también que los sistemas de doble factor que no dependen de códigos no son pruebas cognitivas: llaves físicas como una YubiKey, aplicaciones que piden confirmar que es usted quien inicia sesión, o métodos del sistema operativo como Windows Hello, Touch ID y Face ID.
Por qué la nota «Inaccessibility of CAPTCHA» considera inaccesibles los CAPTCHA
«Inaccessibility of CAPTCHA» es un borrador de nota de grupo (Group Draft Note) del 16 de diciembre de 2021, publicado por el grupo de trabajo Accessible Platform Architectures como actualización de la nota de 2019. No está respaldado por el W3C ni por sus miembros y se presenta como un trabajo en curso. Su diagnóstico es contundente: la propia naturaleza de la tarea interactiva excluye a muchas personas con discapacidad, lo que equivale a negarles el servicio.
Pedir a personas ciegas, con baja visión o con dislexia que lean caracteres distorsionados es pedirles justo la tarea que menos pueden realizar; lo mismo ocurre con el CAPTCHA de audio y las personas sordas o con pérdida auditiva. Los CAPTCHA tradicionales suelen suponer además el dominio del inglés, y de un diseño que da por hecho varios intentos cabe sostener, según la nota, que es inaccesible por diseño para quienes viven con un trastorno de ansiedad y para muchas personas con otras discapacidades cognitivas y del aprendizaje. La nota cita también datos de Cloudflare según los cuales resolver un CAPTCHA lleva de media 32 segundos.
La nota añade que el CAPTCHA es cada vez menos eficaz como medida de seguridad: los enfoques basados en imágenes, lógica o audio pueden ser descifrados en gran medida por algoritmos. Cita un estudio de la Universidad de Maryland con un 90 % de éxito contra el reCAPTCHA de audio de Google.
Alternativas al CAPTCHA que presenta la nota
En igualdad de condiciones, los autores de la nota prefieren los enfoques no interactivos porque no plantean problemas de accesibilidad, aunque advierten de que pueden exponer datos personales. La página Understanding del criterio 3.3.8 menciona también la limitación del ritmo de acceso, la geolocalización del cliente y la autenticación privada del cliente: ninguno es eficaz al 100 %, pero pueden reducir la probabilidad de mostrar un CAPTCHA.
- Filtrado de spam (palabras clave, filtrado bayesiano): sistemas bien ajustados pueden igualar a un CAPTCHA visual sin carga cognitiva.
- Prueba de trabajo: un cálculo en JavaScript en el cliente que verifica el servidor, sin problema directo de accesibilidad, aunque puede ralentizar equipos antiguos.
- Heurísticas: detectar robots por el volumen de datos solicitado, las páginas visitadas, las direcciones IP o la forma de introducir datos.
- Honeypot: un campo visible para los robots pero oculto para las personas, fácil de implementar.
- Cuentas de uso limitado: limitar la frecuencia de interacción de las cuentas nuevas.
- Entre los enfoques interactivos, la biometría con varios identificadores a elegir o la atestación criptográfica de persona basada en WebAuthn.
- Tokens como Privacy Pass: todavía empiezan con un desafío CAPTCHA, pero reducen mucho los desafíos interactivos posteriores.
- Si un CAPTCHA interactivo sigue siendo necesario: mostrarlo lo menos posible y ofrecer varios desafíos que recurran a capacidades sensoriales y cognitivas distintas.
Cómo revisar su proceso de inicio de sesión
Recorra cada paso, incluidos el doble factor, la recuperación de cuenta y las pruebas que solo aparecen tras errores. Pegue una contraseña y un código desde un gestor: deben aceptarse completos. Compruebe que el gestor rellena los campos y que estos tienen un nombre accesible. Si queda un CAPTCHA, asegúrese de que existe otra vía de acceso sin prueba cognitiva. Para el resto de sus páginas, una prueba gratuita y la supervisión continua con Conformly le ayudan a seguir su nivel de accesibilidad en el tiempo.
Preguntas frecuentes
¿Las WCAG prohíben el CAPTCHA?
No como tal. El criterio 3.3.8 exige que un paso de autenticación no dependa de una prueba cognitiva sin alternativa ni mecanismo de ayuda; un CAPTCHA de reconocimiento de objetos sigue admitiéndose en el nivel AA. La nota del W3C recuerda además que las WCAG permiten los CAPTCHA si tienen alternativas textuales que identifican y describen su propósito y formas alternativas que usan otros modos de percepción.
¿Bloquear pegar la contraseña incumple el criterio 3.3.8?
Sí. Impedir pegar en los campos de autenticación obliga a transcribir e incumple el criterio, salvo que se ofrezca otro método de autenticación sin prueba cognitiva.
¿Es accesible un CAPTCHA de «seleccione los coches»?
Se beneficia de la excepción de reconocimiento de objetos del criterio 3.3.8 (nivel AA), pero esa excepción no existe en el 3.3.9 (nivel AAA). El W3C aconseja evitarlo si es posible, la excepción deja de aplicarse si la prueba va más allá del simple reconocimiento, y los demás pasos de la autenticación también deben cumplir el criterio.
¿Basta con la alternativa de audio de un CAPTCHA?
No, si el usuario debe transcribir lo que oye: no puede servir como alternativa según el 3.3.8. La nota sobre CAPTCHA añade que los CAPTCHA de audio imponen a todos los usuarios una sobrecarga cognitiva frente a la necesaria para entender el habla normal, y que transcribir un CAPTCHA de audio es justo la tarea que menos probabilidades tienen de lograr las personas sordas, con pérdida auditiva o con trastorno del procesamiento auditivo.
¿El criterio 3.3.8 se aplica al registro de cuentas?
No, cubre la autenticación de usuarios existentes, incluida la recuperación de la cuenta. Aun así, permitir pegar y evitar la transcripción también facilitan el registro.
¿Cuál es la alternativa más accesible al CAPTCHA?
Los autores de la nota del W3C sobre CAPTCHA prefieren los enfoques no interactivos, como el honeypot, el filtrado de spam, las heurísticas o la prueba de trabajo, que según ellos no plantean problemas de accesibilidad, aunque pueden exponer datos personales. Aconsejan ajustar la protección al riesgo real, por ejemplo usar un honeypot mientras sea suficiente.
Más sobre el tema en Conformly
Fuentes
Este artículo se basa en las fuentes oficiales citadas al final de la página.