WCAG 3.3.8: Autenticación accesible (mínimo)

Qué significa esta regla

WCAG 3.3.8 Autenticación accesible (mínima) es un criterio de nivel AA introducido en WCAG 2.2. Establece que una prueba de función cognitiva —definida como una tarea que requiere que una persona usuaria recuerde, manipule o transcriba información— no debe ser el único medio para completar un paso de autenticación, a menos que se cumpla al menos una de las siguientes condiciones:

• Método alternativo: Hay disponible otra vía de autenticación que no depende de una prueba de función cognitiva (por ejemplo, un enlace mágico enviado por correo electrónico, inicio de sesión biométrico o una passkey).
• Mecanismo de asistencia: Se permite que el agente de usuario o una herramienta de terceros complete el paso en nombre de la persona usuaria; por ejemplo, un gestor de contraseñas que autocompleta las credenciales o una acción de copiar y pegar para un código de un solo uso.
• Excepción de reconocimiento de objetos: La prueba de función cognitiva consiste en identificar un objeto en una imagen (por ejemplo, seleccionar todas las imágenes que contienen un semáforo); este tipo de prueba está permitida en el nivel mínimo (AA).
• Excepción de contenido personal: La prueba se basa en contenido proporcionado por la propia persona usuaria, como seleccionar una foto previamente subida de una cuadrícula.

En términos prácticos, un formulario de inicio de sesión que solo requiere nombre de usuario y contraseña sí cumple este criterio, siempre que el formulario permita que el autocompletado del navegador y los gestores de contraseñas funcionen (es decir, que los campos usen <input type='password'> estándar y no bloqueen el pegado). Un CAPTCHA que requiere transcribir texto distorsionado sin ninguna ruta alternativa de autenticación es un incumplimiento claro. Un CAPTCHA que pide a las personas usuarias seleccionar imágenes que coincidan con una categoría (reconocimiento de objetos) está permitido en el nivel AA, pero se trata de forma más estricta en AAA (3.3.9).

El criterio se aplica a todos los pasos de un proceso de autenticación: inicio de sesión inicial, autenticación reforzada, verificación multifactor, recuperación de cuenta y reautenticación de sesión. También se aplica a cualquier proceso que proteja el acceso a funcionalidades, no solo a la pantalla principal de inicio de sesión.

Una implicación técnica clave es que las personas desarrolladoras no deben usar autocomplete='off' en campos de autenticación, no deben deshabilitar el pegado mediante controladores de eventos JavaScript y no deben romper las semánticas estándar de entrada que permiten que la tecnología de asistencia y el autocompletado del navegador funcionen correctamente.

Por qué es importante

La autenticación es la puerta de entrada a casi todos los servicios digitales de los que la gente depende a diario: banca, portales de salud, servicios gubernamentales, comercio electrónico y plataformas de comunicación. Cuando esa puerta impone obstáculos cognitivos, excluye sistemáticamente a una parte significativa de la población.

Las discapacidades cognitivas abarcan un amplio espectro: dislexia, discalculia, trastornos por déficit de atención, lesiones cerebrales adquiridas, demencia, discapacidades intelectuales y trastornos de ansiedad. La Organización Mundial de la Salud estima que aproximadamente 1 de cada 6 personas en el mundo experimenta algún tipo de discapacidad significativa, y las condiciones cognitivas y neurológicas representan una de las categorías más grandes. Para estas personas, tareas como transcribir con precisión una cadena de caracteres distorsionados, resolver un rompecabezas visual bajo presión de tiempo o alternar entre una app de autenticación y un formulario de inicio de sesión pueden ser realmente imposibles o profundamente agotadoras.

Considere un escenario concreto: una persona con dislexia intenta iniciar sesión en el portal de su seguro de salud para ver resultados de pruebas. El sitio presenta un CAPTCHA de texto sin alternativa de audio y sin forma de omitirlo. Las formas de las letras distorsionadas son indistinguibles para esta persona, y el campo de entrada bloquea el pegado. Tras varios intentos fallidos, la cuenta se bloquea. La persona no puede acceder a información médica sensible al tiempo. Esto no es un caso hipotético extremo: es una experiencia habitual para millones de personas.

Las personas con discapacidad motora que dependen de acceso por pulsadores o dispositivos de seguimiento ocular también se ven afectadas. Volver a escribir un código de un solo uso complejo desde un dispositivo separado, o arrastrar mosaicos de imágenes en un orden específico, puede ser físicamente imposible con estos métodos de entrada. Permitir copiar y pegar o la autenticación basada en passkeys elimina por completo la barrera.

Las personas mayores representan otro grupo significativo. El deterioro cognitivo relacionado con la edad afecta la memoria y la velocidad de procesamiento, lo que hace que los CAPTCHAs complejos y las tareas de memorización de varios pasos sean desproporcionadamente difíciles. A medida que las poblaciones de Turquía y del mundo envejecen, el argumento empresarial y regulatorio a favor de la autenticación accesible se fortalece cada año.

Desde la perspectiva de usabilidad y conversión, la fricción en los flujos de autenticación incrementa directamente las tasas de abandono. Las plataformas de comercio electrónico que sustituyen los CAPTCHAs de texto por autenticación basada en riesgos o passkeys informan de forma constante mayores tasas de finalización de inicio de sesión y menores costos de soporte relacionados con cuentas bloqueadas.

Reglas relacionadas de Axe-core

WCAG 3.3.8 se clasifica como un criterio que requiere pruebas manuales porque las herramientas automatizadas no pueden evaluar completamente si un proceso de autenticación impone una prueba de función cognitiva inaccesible. Determinar si un flujo de inicio de sesión no tiene una vía alternativa, o si el pegado se bloquea de forma dependiente del contexto, requiere juicio humano e interacción con un flujo de autenticación en vivo. Dicho esto, ciertas comprobaciones automatizadas respaldan este criterio:

• Revisión manual — auditoría del flujo de autenticación: Las personas evaluadoras deben recorrer cada paso de autenticación y determinar si hay una prueba de función cognitiva y, en caso afirmativo, si existe una alternativa o un mecanismo de asistencia que cumpla. Actualmente ninguna regla de axe-core se dispara automáticamente para este criterio porque la lógica depende de entender el propósito y el contexto de los campos de formulario y la interfaz circundante, no solo su marcado.
• Comprobaciones del atributo autocomplete (relacionadas): La regla autocomplete-valid de axe-core marca los campos de entrada cuyo valor del atributo autocomplete no se toma de la lista de tokens de WCAG 1.3.5. Aunque esta regla se dirige directamente a 1.3.5, es una comprobación de apoyo para 3.3.8: si autocomplete='username' y autocomplete='current-password' faltan o están configurados incorrectamente, los gestores de contraseñas no pueden autocompletar, eliminando el mecanismo de asistencia que hace que el inicio de sesión estándar con contraseña cumpla con 3.3.8.
• Detección de bloqueo de pegado — manual: Los escáneres automatizados no pueden detectar de forma fiable JavaScript que intercepta eventos de paste y los suprime en entradas de autenticación. Una persona evaluadora debe intentar pegar una credencial u OTP en cada campo relevante y confirmar que la acción tiene éxito.
• Detección de alternativas a CAPTCHA — manual: Axe-core puede detectar la presencia de widgets CAPTCHA comunes (por ejemplo, iframes de reCAPTCHA), pero no puede determinar si se ofrece una vía alternativa de autenticación en otra parte de la página o mediante una ruta diferente. Esta determinación requiere una inspección manual de toda la experiencia de autenticación.

Cómo probar

1. Escaneo automatizado (axe DevTools / Lighthouse): Ejecute axe DevTools en cada página de autenticación (inicio de sesión, registro, recuperación de cuenta, MFA). Busque infracciones de autocomplete-valid en los campos de nombre de usuario y contraseña. En Lighthouse, revise la auditoría de accesibilidad en busca de problemas relacionados con formularios. Tenga en cuenta que ninguna regla automatizada señalará de forma definitiva un incumplimiento de 3.3.8: los resultados automatizados son solo un punto de partida.
2. Identificar todas las pruebas de función cognitiva: Catalogue manualmente cada paso del flujo de autenticación. Anote cualquier paso que requiera que la persona usuaria recuerde información que no se proporciona en la pantalla actual, transcriba caracteres, resuelva un rompecabezas o realice un cálculo. Compruebe si cada uno de estos pasos tiene una alternativa que cumpla (reconocimiento de objetos, contenido personal, método de inicio de sesión alternativo o mecanismo de asistencia).
3. Probar la funcionalidad de pegado: En cada entrada de autenticación (nombre de usuario, contraseña, OTP, código de recuperación), intente pegar texto usando el atajo de teclado (Ctrl+V en Windows/Linux, Cmd+V en macOS). Confirme que el contenido pegado aparece en el campo. Repita usando el menú contextual de clic derecho. Si el pegado está bloqueado, esto es un incumplimiento a menos que exista una alternativa libre de función cognitiva.
4. Probar el autocompletado con un gestor de contraseñas: Usando un navegador con un gestor de contraseñas (nativo o basado en extensión), guarde las credenciales durante el registro y luego vuelva a la página de inicio de sesión. Confirme que el gestor de contraseñas puede detectar los campos y autocompletarlos. Pruebe en Firefox con NVDA, Safari con VoiceOver (macOS/iOS) y Chrome con JAWS para cubrir las principales combinaciones de tecnología de asistencia + navegador. Si los campos usan marcado no estándar o JavaScript que borra los valores autocompletados, esto es un incumplimiento.
5. NVDA + Firefox — recorrido con lector de pantalla: Navegue por el formulario de inicio de sesión usando solo el teclado y NVDA. Confirme que se puede llegar a cada campo, que las etiquetas de los campos se anuncian correctamente y que cualquier widget CAPTCHA tiene una alternativa accesible. Si el CAPTCHA es puramente visual, sin opción de audio y sin vía alternativa de inicio de sesión, registre un incumplimiento.
6. VoiceOver + Safari (iOS): En un dispositivo móvil, intente iniciar sesión usando Face ID o Touch ID si el sitio ofrece inicio de sesión biométrico. Confirme que la opción biométrica es alcanzable mediante navegación por deslizamiento y que VoiceOver la anuncia correctamente. Esto valida que una alternativa libre de función cognitiva es accesible operativamente, no solo está presente de forma nominal.
7. Comprobar límites de tiempo en pasos cognitivos: Si un CAPTCHA o la introducción de una OTP impone un límite de tiempo, verifique si la persona usuaria puede ampliarlo o desactivarlo (relevante para 2.2.1) y, por separado, anote si el paso cronometrado constituye una prueba de función cognitiva sin alternativa.

Cómo corregir

CAPTCHA de texto sin alternativa — Incorrecto

<!-- Fails 3.3.8: only authentication method is transcribing distorted text;
     no alternative login path is offered, and paste is disabled -->
<form action='/login' method='post'>
  <label for='user'>Username</label>
  <input type='text' id='user' name='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='off'
         onpaste='return false;'>

  <img src='/captcha-image.png' alt=''>
  <label for='captcha'>Type the characters above</label>
  <input type='text' id='captcha' name='captcha'
         autocomplete='off'
         onpaste='return false;'>

  <button type='submit'>Log in</button>
</form>

CAPTCHA de texto sin alternativa — Correcto

<!-- Passes 3.3.8: text CAPTCHA is replaced with a passkey / magic-link option;
     password field supports autofill and paste so password managers can assist -->
<form action='/login' method='post'>
  <label for='user'>Username or email</label>
  <input type='text' id='user' name='username'
         autocomplete='username'>

  <label for='pass'>Password</label>
  <input type='password' id='pass' name='password'
         autocomplete='current-password'>

  <!-- No CAPTCHA; bot protection handled server-side via risk-based signals -->
  <button type='submit'>Log in</button>
</form>

<!-- Cognitive-function-free alternative always visible -->
<p><a href='/magic-link'>Send me a sign-in link by email instead</a></p>
<p><a href='/passkey-login'>Sign in with a passkey or biometrics</a></p>

Campo de OTP que bloquea el pegado — Incorrecto

<!-- Fails 3.3.8: user must manually type a 6-digit OTP;
     paste is suppressed, forcing a transcription task -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='off'
       onpaste='event.preventDefault();'
       ondrop='event.preventDefault();'>

Campo de OTP que bloquea el pegado — Correcto

<!-- Passes 3.3.8: paste and autofill are permitted;
     autocomplete='one-time-code' enables OS-level SMS/OTP autofill on mobile -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp'
       inputmode='numeric'
       maxlength='6'
       autocomplete='one-time-code'>
<!-- Remove all paste/drop prevention handlers.
     Risk of credential stuffing is managed server-side, not by blocking paste. -->

CAPTCHA de selección de imágenes sin alternativa (preocupación AAA, aprobado en AA) — Correcto en AA

<!-- Passes 3.3.8 (AA): object recognition CAPTCHAs are explicitly
     exempted at the Minimum level. Selecting images of bicycles
     qualifies as object recognition, not character transcription.
     Note: this would fail 3.3.9 (AAA) — provide an alternative for full conformance. -->
<fieldset>
  <legend>Select all images that contain a bicycle</legend>
  <ul role='list'>
    <li>
      <input type='checkbox' id='img1' name='captcha' value='1'>
      <label for='img1'>
        <img src='/grid/img1.jpg' alt='A city street with parked vehicles'>
      </label>
    </li>
    <!-- additional grid items -->
  </ul>
</fieldset>

Errores comunes

• Configurar autocomplete='off' en campos de contraseña: Esto deshabilita el autocompletado de los gestores de contraseñas, eliminando el mecanismo de asistencia que hace que la autenticación estándar con contraseña cumpla el criterio. Use autocomplete='current-password' en su lugar y deje que el navegador gestione el almacenamiento de credenciales.
• Bloquear el pegado con onpaste='return false;' o addEventListener('paste', e => e.preventDefault()): Esto obliga a las personas usuarias a escribir manualmente las credenciales, creando una tarea de transcripción inaccesible. Elimine todos los controladores de prevención de pegado de las entradas de autenticación.
• Ofrecer una opción de passkey que no sea accesible por teclado: Una alternativa biométrica solo satisface 3.3.8 si es alcanzable y operable mediante teclado y tecnología de asistencia. Un botón de passkey oculto detrás de un menú que aparece al pasar el cursor o renderizado como un <div> no enfocable no cuenta como alternativa que cumpla el criterio.
• Usar un CAPTCHA de texto como única estrategia de mitigación de bots: Cambiar a detección de bots del lado del servidor basada en riesgos (analizando huella del dispositivo, cadencia de escritura, reputación de IP) elimina por completo la prueba de función cognitiva sin sacrificar seguridad. Confiar únicamente en CAPTCHA del lado del cliente es tanto un fallo de accesibilidad como una mala práctica de seguridad.
• Dividir una OTP en múltiples entradas de un solo carácter y bloquear el pegado entre campos: Algunas implementaciones usan seis campos <input maxlength='1'> separados para la introducción de la OTP y avanzan el foco automáticamente mediante JavaScript. Este patrón rompe de forma habitual el pegado desde gestores de contraseñas y viola 3.3.8 a menos que la implementación gestione explícitamente pegar un código completo en el primer campo y distribuya los caracteres correctamente.
• Requerir CAPTCHA basado en imágenes solo en flujos de recuperación de cuenta: Los equipos a menudo añaden alternativas de inicio de sesión accesibles a la página principal de inicio de sesión, pero olvidan la autenticación reforzada, el restablecimiento de contraseña y los flujos de desbloqueo de cuenta. Cada uno de estos es un paso de autenticación independiente y debe cumplir 3.3.8 por separado.
• Tratar el CAPTCHA de audio como alternativa completa al CAPTCHA de texto: Una alternativa de audio atiende a personas ciegas, pero no ayuda a personas con discapacidades cognitivas o a quienes se encuentran en entornos ruidosos. Los CAPTCHAs de audio también presentan su propio requisito de transcripción. La solución correcta es eliminar el CAPTCHA o proporcionar una vía que no tenga ninguna prueba de función cognitiva.
• Generar dinámicamente IDs de campos de entrada que rompen la detección de los gestores de contraseñas: Cuando los atributos id de los campos de nombre de usuario y contraseña se aleatorizan en cada carga de página (una técnica equivocada contra bots), los gestores de contraseñas no pueden identificar de forma fiable los campos. Esto deshabilita efectivamente el autocompletado y elimina el mecanismo de asistencia que cumple el criterio.
• Suponer que los widgets CAPTCHA de terceros cumplen automáticamente: Los servicios CAPTCHA populares pueden ofrecer variantes accesibles, pero no están habilitadas por defecto. Las personas desarrolladoras deben configurar explícitamente la versión accesible y aun así verificar que cumple los requisitos del estándar en lugar de simplemente añadir un nuevo tipo de prueba inaccesible.
• Borrar valores autocompletados mediante JavaScript al enfocar: Algunos formularios borran el contenido de entrada cuando un campo recibe el foco para mostrar texto de marcador de posición o solicitar reintroducción. Si este comportamiento borra el valor autocompletado por un gestor de contraseñas, obliga a la reintroducción manual y no cumple 3.3.8.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece obligaciones de accesibilidad web y móvil alineadas con WCAG 2.2. La circular exige que las entidades cubiertas alcancen conformidad de nivel AA en todos sus productos y servicios digitales. WCAG 3.3.8, como criterio de nivel AA en WCAG 2.2, está por tanto directamente dentro del alcance de los requisitos de cumplimiento obligatorio introducidos por esta circular.

La circular abarca una amplia gama de entidades del sector público y privado. Las instituciones públicas y los organismos gubernamentales deben lograr conformidad AA completa. En el sector privado, la circular se aplica a plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores privados de atención sanitaria, operadores de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Para estas organizaciones, los flujos de autenticación inaccesibles —como páginas de inicio de sesión con CAPTCHAs no compatibles o campos de OTP que bloquean el pegado— crean una exposición regulatoria directa.

El Logotipo de Accesibilidad (Erişilebilirlik Logosu), emitido por el Ministerio de Familia y Servicios Sociales, es la marca oficial de certificación de conformidad en accesibilidad digital en Turquía. Obtener este logotipo requiere demostrar conformidad de nivel AA, que incluye 3.3.8. Para operadores de comercio electrónico, bancos y otros proveedores de servicios digitales de alto tráfico, el logotipo sirve como señal de confianza pública y puede mencionarse en requisitos de contratación y licitación. Los flujos de autenticación que dependen de pruebas cognitivas inaccesibles bloquearían la certificación y expondrían a la organización a quejas y acciones de cumplimiento.

Desde una perspectiva práctica de cumplimiento, las organizaciones turcas deberían auditar cada punto de contacto de autenticación —incluidos inicio de sesión, registro, MFA, restablecimiento de contraseña y desbloqueo de cuenta— con respecto a 3.3.8 antes de presentarse a la evaluación del Logotipo de Accesibilidad. Sustituir los CAPTCHAs de texto por controles basados en riesgos del lado del servidor, habilitar autocomplete en todos los campos de credenciales y ofrecer alternativas de passkey o enlace mágico son las acciones de remediación de mayor impacto. Estos cambios satisfacen simultáneamente el requisito normativo y mejoran la experiencia de autenticación para los aproximadamente 8.5 millones de personas con discapacidad en Turquía que utilizan servicios digitales.