WCAG 3.3.9: Autenticación accesible (mejorada)

Qué significa esta regla

WCAG 3.3.9 — Autenticación accesible (mejorada) es la contraparte de nivel AAA de WCAG 3.3.8 (Autenticación accesible — mínima, AA). Juntas, forman un par de criterios introducidos en WCAG 2.2 diseñados para garantizar que el proceso de demostrar la identidad en un sitio web o aplicación no se convierta en sí mismo en una barrera de accesibilidad.

En el nivel AAA, 3.3.9 endurece significativamente los requisitos. El criterio establece: No se debe requerir una prueba de función cognitiva en ningún paso de un proceso de autenticación a menos que ese paso proporcione al menos uno de los siguientes: un método de autenticación alternativo que no dependa de una prueba de función cognitiva; un mecanismo disponible para ayudar a la persona usuaria a completar la prueba de función cognitiva; o que la prueba de función cognitiva consista en reconocer objetos. De forma crítica, a diferencia de la versión AA (3.3.8), el criterio AAA elimina la excepción que permitía reconocer contenido que no fueran objetos (como imágenes de elementos no objetuales que la persona usuaria hubiera seleccionado anteriormente). En este nivel, solo el reconocimiento de objetos reales —reconocer objetos comunes del mundo real como imágenes de un gato, una bicicleta o una casa— es admisible como prueba de función cognitiva, y solo si no se cumplen las otras condiciones.

Una prueba de función cognitiva se define como cualquier tarea que requiera que la persona usuaria recuerde, manipule o transcriba información. Esto incluye: recordar un nombre de usuario o contraseña, resolver un rompecabezas matemático, completar un CAPTCHA que requiera descifrar texto distorsionado, responder una pregunta de seguridad sobre la historia personal (por ejemplo, "¿Cuál era el nombre de tu primera mascota?") o transcribir una secuencia de caracteres. Todas estas son tareas de memoria o transcripción que muchas personas usuarias no pueden realizar de forma fiable.

Qué se considera un cumplimiento: Un paso de autenticación cumple con 3.3.9 si no requiere ninguna prueba de función cognitiva, o si cumple una de estas condiciones: (1) se ofrece una vía de autenticación completamente separada y no cognitiva (por ejemplo, un enlace mágico enviado por correo electrónico, WebAuthn/passkey, inicio de sesión biométrico); (2) un mecanismo ayuda a completar la prueba (por ejemplo, no se bloquea el gestor de contraseñas del navegador o se permite copiar y pegar); o (3) la única prueba cognitiva implicada es reconocer un objeto común del mundo real a partir de un conjunto de imágenes.

Qué se considera un incumplimiento: Cualquier flujo que obligue a la persona usuaria —sin posibilidad de omitirlo ni alternativa— a recordar una contraseña de memoria, transcribir un código que no se puede pegar, resolver un CAPTCHA visual o de audio sin alternativa, responder preguntas de seguridad basadas en conocimientos o identificar imágenes previamente seleccionadas de contenido que no sean objetos (por ejemplo, formas abstractas o fotos personales) sin una vía de autenticación alternativa.

Excepciones oficiales: La propia especificación WCAG señala que el reconocimiento de objetos (fotografías de cosas del mundo real) es la única tarea de reconocimiento de imágenes permitida en este nivel AAA. El criterio AA (3.3.8) también permitía reconocer imágenes "no objetuales" elegidas personalmente, pero 3.3.9 elimina por completo esa excepción. No hay excepción para patrones de autenticación "ampliamente utilizados": si un patrón requiere una prueba cognitiva sin alternativa, incumple 3.3.9.

Por qué es importante

La autenticación es con frecuencia la primera interacción significativa que una persona usuaria tiene con un servicio digital. Si esa interacción es en sí misma inaccesible, el resto de la accesibilidad del sitio se vuelve irrelevante: la persona usuaria no puede ni siquiera entrar. WCAG 3.3.9 aborda directamente esta barrera, y su impacto abarca a una amplia gama de grupos de personas con discapacidad.

Personas con discapacidades cognitivas —incluidas aquellas con dislexia, TDAH, lesión cerebral traumática, demencia o discapacidades del aprendizaje— pueden encontrar extremadamente difícil o imposible memorizar contraseñas complejas, transcribir manualmente códigos de un solo uso con tiempo limitado o descifrar texto distorsionado en un CAPTCHA. La Organización Mundial de la Salud estima que aproximadamente 1 de cada 6 personas en el mundo experimenta alguna forma de discapacidad significativa, y las discapacidades cognitivas representan una de las categorías más grandes y desatendidas en la accesibilidad web.

Personas con discapacidades motoras —como quienes tienen enfermedad de Parkinson, temblor esencial, lesiones medulares o condiciones que requieren acceso mediante pulsadores o tecnología de seguimiento ocular— pueden tener dificultades para escribir contraseñas con precisión o transcribir códigos carácter por carácter. Bloquear el pegado desde el portapapeles (una medida antifraude común que es activamente perjudicial) significa que estas personas deben introducir laboriosamente cada carácter a través de su tecnología de apoyo, lo que aumenta drásticamente las tasas de error y la fatiga.

Personas ciegas o con baja visión pueden depender por completo de lectores de pantalla o herramientas de aumento. Los CAPTCHAs visuales son completamente inaccesibles sin una alternativa de audio, y aun los CAPTCHAs de audio son notoriamente difíciles para personas con discapacidades auditivas o trastornos del procesamiento auditivo. Los desafíos basados en imágenes del tipo "selecciona todos los semáforos" también pueden ser problemáticos cuando las descripciones de las imágenes están ausentes o son engañosas.

Personas sordas o con discapacidad auditiva pueden enfrentarse a barreras con métodos de autenticación que dependen exclusivamente de llamadas telefónicas para entregar códigos de un solo uso, especialmente cuando esas llamadas son solo de voz y no hay alternativa por SMS.

Un escenario concreto del mundo real: Consideremos a una persona usuaria de 72 años con un deterioro cognitivo leve que intenta acceder a su portal de banca en línea. El banco requiere un nombre de usuario (que debe recordarse, no la dirección de correo electrónico), una contraseña compleja (se bloquea el pegado desde el portapapeles) y un CAPTCHA con texto distorsionado. La persona falla el CAPTCHA dos veces, queda bloqueada y debe llamar a la línea de ayuda del banco, un proceso de 40 minutos. Si el banco hubiera implementado passkeys o un enlace mágico, esta persona se habría autenticado en segundos. Este escenario se repite millones de veces al día en la web, y es completamente evitable.

Más allá de la discapacidad, la autenticación accesible beneficia a todas las personas usuarias. Los gestores de contraseñas, utilizados por cientos de millones de personas, dependen de la capacidad de pegar credenciales. Bloquear el pegado, exigir la transcripción manual o incrustar CAPTCHAs inaccesibles también frustra a las personas usuarias en general. También hay argumentos de seguridad: obligar a introducir manualmente contraseñas complejas aumenta la probabilidad de que las personas elijan contraseñas más simples y débiles o las reutilicen en varios sitios. Las passkeys y los enlaces mágicos, las alternativas recomendadas, son a la vez más accesibles y más seguras que los flujos tradicionales de contraseña más CAPTCHA.

Reglas relacionadas de Axe-core

WCAG 3.3.9 se clasifica como que requiere solo pruebas manuales. A partir de axe-core 4.10, no existe una regla automatizada que evalúe completamente este criterio. Entender por qué las herramientas automatizadas no pueden detectar estas infracciones requiere comprender qué es lo que el criterio está midiendo realmente.

• Se requiere prueba manual — detección de función cognitiva: Los escáneres automatizados pueden detectar la presencia de ciertos elementos HTML (como un <input type='password'> o un iframe que incrusta un widget CAPTCHA de terceros), pero no pueden determinar si un flujo de autenticación completo requiere una prueba de función cognitiva sin alternativa accesible. El criterio se refiere a todo el recorrido de la persona usuaria a través de potencialmente múltiples pasos y páginas, no a las propiedades de un solo elemento. Un escáner no puede evaluar si el pegado se bloquea de forma programática mediante JavaScript, si el límite de tiempo en un campo de introducción de código es razonable o si una vía de autenticación alternativa realmente evita las pruebas cognitivas. Estas son cuestiones de comportamiento y arquitectura que requieren que una persona evaluadora recorra el proceso de autenticación real.
• Se requiere prueba manual — verificación de la vía alternativa: Incluso si un escáner detecta un widget CAPTCHA, no puede verificar si existe un método de autenticación alternativo accesible en la misma página o en el mismo flujo. No puede evaluar si una opción como "usar una passkey en su lugar" es realmente equivalente o si está escondida en una página de configuración secundaria que a su vez requiere superar primero el CAPTCHA inaccesible. Evaluar la equivalencia de las vías alternativas requiere juicio humano sobre la completitud y prominencia de esas alternativas.
• Se requiere prueba manual — comportamiento del pegado desde el portapapeles: El JavaScript que intercepta eventos de paste y los cancela (event.preventDefault() en un listener de pegado) es invisible para el análisis estático de HTML. Un escáner ve un elemento <input> válido; no puede saber que se ha deshabilitado el pegado en él. Solo las pruebas manuales —intentar físicamente pegar una contraseña o un código— pueden revelar este fallo.
• Se requiere prueba manual — compatibilidad de los widgets de autenticación con tecnologías de apoyo: Los SDK de autenticación de terceros (botones de inicio de sesión social, proveedores de CAPTCHA, avisos biométricos) pueden renderizarse en iframes o Shadow DOM a los que los escáneres automatizados no pueden acceder completamente. Las pruebas manuales con lectores de pantalla como NVDA, JAWS y VoiceOver son esenciales para confirmar que todos los elementos interactivos dentro del flujo de autenticación sean operables y comprensibles.

Cómo hacer las pruebas

1. Identificar todos los puntos de entrada de autenticación: Antes de probar, mapea todos los lugares de la aplicación donde una persona usuaria deba autenticarse o verificar su identidad. Esto incluye el inicio de sesión inicial, la creación de cuenta, el restablecimiento de contraseña, los avisos de autenticación de dos factores, la reautenticación por tiempo de sesión, las pantallas de confirmación de pago y las barreras de verificación de edad. Cada uno de estos flujos debe evaluarse de forma independiente.
2. Ejecutar un escaneo automatizado de referencia: Usa axe DevTools (extensión del navegador) o Lighthouse en Chrome DevTools en cada página de autenticación. Aunque estas herramientas no señalarán directamente infracciones de 3.3.9, sí sacarán a la luz problemas relacionados —etiquetas faltantes en campos de formulario, contenido inaccesible en iframes, gestión de foco ausente— que agravan las barreras de autenticación. Anota cualquier problema señalado como contexto para la evaluación manual. En axe DevTools, revisa la pestaña "Needs Review" para ver los elementos que requieren juicio manual.
3. Auditar las pruebas de función cognitiva: Para cada paso de autenticación, pregúntate: ¿este paso requiere que la persona usuaria (a) recuerde algo, (b) transcriba algo o (c) resuelva un rompecabezas? Si la respuesta es sí, verifica que al menos una de las siguientes condiciones esté presente y sea igualmente prominente: una vía alternativa no cognitiva; un mecanismo (como permitir el pegado desde el portapapeles o un campo compatible con autocompletado) que ayude a completar la tarea; o que la única tarea cognitiva sea reconocer un objeto común del mundo real.
4. Probar el comportamiento del pegado desde el portapapeles: En cada campo de contraseña y de introducción de códigos, copia una cadena de texto en tu portapapeles e intenta pegarla usando Ctrl+V (Windows/Linux) o Cmd+V (macOS). Si el pegado está bloqueado, se trata de un fallo. También prueba si se suprime el autocompletado del gestor de contraseñas del navegador (busca autocomplete='off' o JavaScript que borre los valores de autocompletado al enfocar).
5. Probar con NVDA + Firefox: Navega por todo el flujo de autenticación usando solo el teclado y el lector de pantalla NVDA. Verifica que todos los campos de formulario se anuncien con etiquetas significativas, que todos los controles interactivos (botones, enlaces, desafíos CAPTCHA) sean alcanzables y operables, y que cualquier mensaje de error esté asociado de forma programática con el campo correspondiente y se anuncie de inmediato sin requerir navegación adicional.
6. Probar con VoiceOver + Safari (macOS/iOS): Repite el flujo completo de autenticación. En iOS, verifica también que se ofrezca la autenticación biométrica (Face ID / Touch ID) como alternativa cuando se use autenticación nativa, y que el flujo basado en la web sea totalmente operable con Control por Botón (Switch Control) si la biometría no está disponible.
7. Probar con JAWS + Chrome: Repite el flujo, prestando especial atención a cómo se anuncian los widgets de terceros (inicio de sesión social OAuth, iframes de CAPTCHA). JAWS maneja ciertos patrones ARIA de forma diferente a NVDA; es necesario probar con ambos.
8. Evaluar la verdadera equivalencia de las vías alternativas: Si existe un método de autenticación alternativo (por ejemplo, "Iniciar sesión con un enlace mágico"), completa todo el flujo usando solo esa alternativa. Confirma que se alcanza el mismo estado autenticado sin requerir ninguna prueba cognitiva. Si la propia vía alternativa contiene un CAPTCHA o una prueba de memoria, no es una alternativa válida según 3.3.9.
9. Documentar los hallazgos con evidencias: Para cada fallo, captura una grabación de pantalla o una captura de pantalla anotada que muestre exactamente qué paso falla y por qué. Esta documentación es esencial para la entrega de tareas de corrección a los equipos de desarrollo y para fines de trazabilidad de auditoría.

Cómo corregir

CAPTCHA sin alternativa — Incorrecto

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

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

CAPTCHA reemplazado por passkey y enlace mágico — Correcto

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

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

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

Pegado desde el portapapeles bloqueado en el campo OTP — Incorrecto

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

Campo OTP con pegado habilitado y sugerencia de autocompletado — Correcto

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

Preguntas de seguridad basadas en conocimientos — Incorrecto

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

Verificación de identidad con alternativas no cognitivas — Correcto

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

  <button type='submit'>Continue</button>
</form>

Errores comunes

• Añadir autocomplete='off' a los campos de contraseña para impedir el autocompletado del navegador. Esto deshabilita el mecanismo principal que permite a las personas usuarias evitar memorizar contraseñas e incumple directamente 3.3.9. Elimina autocomplete='off' y usa autocomplete='current-password' o autocomplete='new-password' en su lugar.
• Adjuntar un listener de evento de JavaScript paste que llame a event.preventDefault() en campos de entrada de autenticación, creyendo que esto mejora la seguridad. En realidad, bloquea los gestores de contraseñas y las tecnologías de apoyo y constituye un requisito de transcripción según 3.3.9.
• Tratar la alternativa de CAPTCHA de audio como un desvío suficiente para los CAPTCHAs visuales. Los CAPTCHAs de audio siguen constituyendo una prueba de función cognitiva (transcribir caracteres de audio distorsionados) y no satisfacen 3.3.9. Se requiere una vía alternativa verdaderamente no cognitiva.
• Ofrecer una passkey o una opción de inicio de sesión social pero situarla detrás de un desafío CAPTCHA primero. Si la persona usuaria debe superar una prueba cognitiva para acceder a la alternativa accesible, la alternativa no es realmente equivalente y el flujo incumple 3.3.9.
• Usar seis campos <input> separados de un solo carácter para la introducción de OTP (un patrón de interfaz común) sin admitir el pegado para rellenar todos los campos. Muchas implementaciones solo pegan en el primer campo y requieren la introducción manual carácter por carácter en los cinco restantes, lo que supone una barrera de transcripción.
• Confiar en "Recuérdame" o en cookies de sesión persistentes como la única adaptación para personas que no pueden autenticarse repetidamente. Aunque reducir la frecuencia de autenticación ayuda, no corrige un proceso de autenticación inaccesible: las personas usuarias aún deben superar la prueba cognitiva al menos una vez, y las sesiones caducan o se borran.
• Implementar campos OTP con límite de tiempo que se borran al expirar sin aviso, obligando a las personas usuarias a solicitar un nuevo código e intentar la transcripción de nuevo. Esto aumenta la carga cognitiva para personas con velocidades de procesamiento motor o cognitivo lentas.
• Usar desafíos CAPTCHA basados en imágenes que requieran reconocer contenido que no sean objetos, como patrones abstractos, colores o secuencias de fotos personales seleccionadas, y creer que esto cumple 3.3.9. El criterio AAA solo permite el reconocimiento de objetos (objetos del mundo real como coches, bicicletas, semáforos); el reconocimiento de imágenes no objetuales no está exento en este nivel.
• Bloquear el acceso al gestor de credenciales del navegador mediante autocomplete='new-password' en campos de inicio de sesión (en lugar de en campos de registro). El valor new-password indica a los navegadores que se trata de un campo para crear una nueva contraseña, lo que impide el autocompletado de credenciales guardadas durante el inicio de sesión.
• No probar los flujos de autenticación con tecnologías de apoyo reales y confiar únicamente en los resultados de escaneos automatizados. Dado que 3.3.9 solo se puede probar manualmente, los equipos que omiten las pruebas manuales con lectores de pantalla y teclado pasarán por alto sistemáticamente fallos en este criterio en cada ciclo de publicación.

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

La Circular Presidencial n.º 2025/10 de Turquía, publicada en el Boletín Oficial n.º 32933 el 21 de junio de 2025, establece obligaciones integrales de accesibilidad web y móvil para una amplia gama de entidades públicas y privadas que operan en Turquía. La circular exige la conformidad con WCAG 2.2, lo que la convierte en el primer instrumento jurídico turco que hace referencia explícita a la versión 2.2 de la norma.

Las entidades cubiertas por la circular incluyen: instituciones y organismos públicos en todos los niveles de gobierno; plataformas de comercio electrónico y mercados en línea; bancos e instituciones financieras; hospitales y proveedores 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 servicios digitales —incluidos portales de inicio de sesión, portales de pacientes, paneles de banca, sistemas de emisión de billetes y sistemas de información estudiantil— deben cumplir los requisitos de accesibilidad definidos por la circular.

WCAG 3.3.9, como criterio de nivel AAA, no es una obligación legal mínima según la circular. La base legal obligatoria corresponde a la conformidad con WCAG 2.2 en los niveles A y AA. Sin embargo, el espíritu y el alcance de la circular hacen que 3.3.9 sea muy relevante en la práctica por varias razones.

En primer lugar, WCAG 3.3.8 (Autenticación accesible — mínima) sí es un requisito de nivel AA y, por tanto, es jurídicamente vinculante para todas las entidades cubiertas. Las organizaciones que trabajen para cumplir con 3.3.8 descubrirán que el camino hacia el cumplimiento de 3.3.9 suele ser un pequeño paso incremental: principalmente eliminar la excepción de reconocimiento de imágenes que permite 3.3.8 y garantizar que todas las pruebas cognitivas tengan alternativas no cognitivas, no solo mecanismos de ayuda.

En segundo lugar, para las entidades que prestan servicios a poblaciones con tasas más altas de discapacidad cognitiva o motora —en particular hospitales, portales públicos de atención sanitaria y portales de servicios gubernamentales— lograr la conformidad AAA en los criterios de autenticación representa un compromiso significativo con el acceso igualitario que se alinea con los principios constitucionales más amplios de igualdad de Turquía y con las obligaciones del país en virtud de la Convención de la ONU sobre los Derechos de las Personas con Discapacidad (CDPD), que Turquía ha ratificado.

En tercer lugar, los bancos turcos y los proveedores de tecnología financiera están sometidos a un escrutinio particular en materia de autenticación. La Agencia de Regulación y Supervisión Bancaria (BDDK) y la Junta de Investigación de Delitos Financieros (MASAK) imponen requisitos estrictos de verificación de identidad, y las organizaciones suelen implementar flujos de autenticación complejos y de varios pasos para satisfacer estos requisitos. Implementar una autenticación conforme a 3.3.9 —usando passkeys, WebAuthn o flujos de enlaces mágicos— es a la vez más accesible y se alinea con las prácticas modernas de autenticación segura respaldadas por reguladores financieros internacionales, lo que la convierte en un objetivo de diseño que sirve al cumplimiento en múltiples frentes simultáneamente.

Se anima encarecidamente a las organizaciones que busquen diferenciar su postura de accesibilidad, prepararse para un posible endurecimiento regulatorio futuro o prestar servicios a las personas usuarias de forma accesible e inclusiva a tratar WCAG 3.3.9 como un estándar de diseño, no simplemente como una mejora opcional. Implementar vías de autenticación totalmente no cognitivas es cada vez más factible con las API modernas de los navegadores (WebAuthn/passkeys) y los SDK de autenticación, lo que hace que el coste de cumplimiento sea más bajo que nunca mientras que el beneficio —eliminar una de las barreras de accesibilidad más importantes en cualquier producto digital— es considerable.