WCAG 2.2.5: Reautenticación

Qué significa esta regla

WCAG 2.2.5 Re-authenticating pertenece a la Pauta 2.2 (Tiempo suficiente) y es un requisito de Nivel AAA. El criterio establece: «Cuando una sesión autenticada expira, la persona usuaria puede continuar la actividad sin pérdida de datos después de volver a autenticarse.» En términos prácticos, esto significa que si una persona usuaria está a mitad de completar un formulario, finalizar una compra, redactar un mensaje o realizar cualquier tarea de varios pasos en una plataforma autenticada y su sesión caduca, debe poder volver a iniciar sesión y retomar exactamente donde lo dejó, con todos los datos introducidos previamente preservados.

Este criterio está estrechamente relacionado con WCAG 2.2.1 (Tiempo ajustable, Nivel A) y 2.2.4 (Interrupciones, Nivel AAA), pero aborda un escenario específico: el momento en que se cruza un límite de sesión. Mientras que 2.2.1 exige dar a las personas usuarias tiempo suficiente o permitirles extender su sesión, 2.2.5 se ocupa del caso de fallo: lo que ocurre después de que el tiempo haya transcurrido. Ambos trabajan en conjunto: idealmente se extiende la sesión y también se preservan los datos si esta expira.

Para cumplir este criterio, la plataforma debe preservar todos los datos introducidos por la persona usuaria —entradas de texto, opciones seleccionadas, archivos adjuntos, casillas de verificación, botones de opción y cualquier otro estado de formulario— a través de un evento de re-autenticación. Después de que la persona usuaria vuelva a iniciar sesión, se le debe devolver al mismo punto de la actividad que estaba realizando, con sus datos intactos y la tarea completada sin repetición.

Se produce un incumplimiento cuando un tiempo de espera de sesión provoca cualquiera de los siguientes casos: la persona usuaria es redirigida a una página de inicio de sesión y, tras iniciar sesión correctamente, se le envía a la página de inicio en lugar de a la página en la que estaba; los datos del formulario introducidos antes del tiempo de espera se pierden y la persona usuaria debe volver a introducir todo; el estado parcialmente completado de un asistente de varios pasos se restablece; o la persona usuaria simplemente es desconectada sin ningún mecanismo para volver a autenticarse y reanudar.

La especificación oficial de WCAG no define una duración mínima de sesión para este criterio: se aplica independientemente de lo largo o corto que sea el periodo de tiempo de espera. Sin embargo, hay que tener en cuenta que no se proporciona ninguna excepción para la pérdida de datos por motivos de seguridad; se espera que las implementaciones encuentren formas seguras de preservar el estado, como el almacenamiento de sesión en el servidor asociado a la identidad de la persona usuaria, o tokens cifrados en el lado del cliente que sobrevivan al flujo de re-autenticación.

Por qué es importante

Los tiempos de espera de sesión que borran datos crean una carga desproporcionadamente grave para las personas con discapacidad. Muchas personas usuarias con discapacidad necesitan significativamente más tiempo para completar tareas digitales que sus pares sin discapacidad, y a menudo no pueden simplemente «escribir más rápido» o «sortear» un tiempo de espera arbitrario.

Las personas usuarias que son ciegas o tienen baja visión navegan por los formularios utilizando lectores de pantalla, lo cual es inherentemente más lento que el escaneo visual. Una persona ciega que completa un extenso formulario de reclamación de seguro puede dedicar 20 o 30 minutos a navegar cuidadosamente campo por campo, solo para que su trabajo se borre cuando se activa un tiempo de espera de sesión de 15 minutos. Luego debe empezar de nuevo, sin garantía de que lo mismo no vuelva a ocurrir una segunda vez.

Las personas con discapacidades motoras, como quienes utilizan dispositivos de acceso por pulsadores, tecnología de seguimiento ocular o punteros bucales, pueden tardar varias veces más que la media en introducir texto y navegar por formularios. Una persona con ELA o atrofia muscular espinal puede estar redactando un formulario de derivación médica crítica y escribiendo solo unos pocos caracteres por minuto. Los tiempos de espera de sesión que destruyen su trabajo no son una molestia menor; pueden ser una barrera completa para completar tareas esenciales.

Las personas usuarias con discapacidades cognitivas, incluidas aquellas con dislexia, TDAH, lesiones cerebrales traumáticas o demencia, pueden necesitar releer las instrucciones varias veces, hacer pausas para procesar la información o simplemente avanzar más despacio a través de procesos de varios pasos. La investigación muestra de forma consistente que esta población se ve afectada de manera desproporcionada por la presión del tiempo y la pérdida de datos, ambos factores que aumentan la carga cognitiva de intentar empezar de cero.

Considere un escenario concreto del mundo real: una persona con esclerosis múltiple está solicitando una prestación por discapacidad del gobierno a través del portal web de una institución pública. La solicitud tiene 8 pasos y requiere subir documentos médicos, introducir historial laboral y redactar una declaración personal. Llega al paso 6 en 45 minutos, su sesión expira y todos los datos introducidos se pierden. Ahora debe reunir los mismos documentos de nuevo y repetir todo el proceso, pudiendo incluso abandonar la solicitud por completo. Esto no es hipotético: es un patrón documentado repetidamente en la investigación y las pruebas de usabilidad en accesibilidad.

Más allá de la discapacidad, la pérdida de datos por tiempo de espera de sesión afecta a todas las personas usuarias y tiene impactos empresariales medibles: carritos de compra abandonados, registros incompletos y oportunidades de negocio perdidas. Preservar el estado de la sesión es tanto un imperativo de accesibilidad como una práctica sólida de UX y optimización de conversión. Según el Baymard Institute, el abandono de formularios es un factor importante en las tasas de abandono de carritos de comercio electrónico, y la pérdida inesperada de datos es una de las principales razones citadas por las que las personas usuarias no completan compras en línea.

Reglas relacionadas de Axe-core

WCAG 2.2.5 requiere solo pruebas manuales. No existen reglas automatizadas de axe-core que puedan detectar de forma fiable incumplimientos de este criterio. Lo siguiente explica por qué las herramientas automatizadas se quedan cortas y qué deben hacer en su lugar las personas evaluadoras:

• No existe una regla automatizada para la preservación del estado de sesión: Axe-core y motores de accesibilidad automatizados similares operan inspeccionando el DOM actual y evaluando condiciones estáticas o casi estáticas, como relaciones de contraste de color, corrección de atributos ARIA y texto alternativo faltante. No pueden simular el paso del tiempo, desencadenar un evento de expiración de sesión, enviar credenciales de re-autenticación y luego verificar si los datos introducidos previamente se restauraron. Toda esta secuencia es un comportamiento con estado y dependiente del tiempo que requiere la observación de una persona (o de una prueba de extremo a extremo guionizada).
• La detección de tiempos de espera de sesión está fuera del alcance del análisis estático: Incluso si una herramienta automatizada pudiera detectar que una página implementa un tiempo de espera de sesión (por ejemplo, leyendo una etiqueta meta refresh o una llamada JavaScript setTimeout), no puede evaluar qué ocurre con los datos de la persona usuaria después de que se active el tiempo de espera. El comportamiento de preservación de datos reside en la lógica de gestión de sesión del lado del servidor, no en la estructura del DOM que analizan las herramientas automatizadas.
• Complejidad del flujo de re-autenticación: La experiencia de re-autenticación puede implicar varias páginas (formulario de inicio de sesión, solicitud de MFA, redirección), y la restauración del estado puede depender de lógica del lado del servidor, cookies, almacenamiento local o parámetros de URL. Ninguna herramienta de inspección de DOM de una sola página puede rastrear este flujo de varias páginas y múltiples sistemas.
• Por qué las pruebas manuales son esenciales: Una persona evaluadora cualificada debe iniciar manualmente un flujo autenticado, esperar deliberadamente o provocar la expiración de la sesión, completar el proceso de re-autenticación y luego verificar la integridad de los datos. Este es el único método fiable para probar la conformidad. Los análisis automatizados pueden utilizarse como punto de partida para señalar problemas relacionados (como la falta de mecanismos de aviso de sesión cubiertos en 2.2.1), pero no pueden sustituir las pruebas manuales para 2.2.5.

Cómo hacer las pruebas

1. Identificar flujos autenticados con formularios o procesos de varios pasos. Comience mapeando todas las áreas del sitio que requieren autenticación e implican introducción de datos por parte de la persona usuaria: flujos de compra, editores de perfil, formularios de solicitud, sistemas de reserva, interfaces de mensajería y paneles administrativos. Estas son las áreas de mayor riesgo de incumplimientos de 2.2.5.
2. Determinar la duración del tiempo de espera de sesión. Revise la configuración del servidor, los ajustes de la aplicación o consulte con el equipo de desarrollo para averiguar cuándo expiran las sesiones. Alternativamente, inicie una sesión y espere hasta que se cierre automáticamente. Tome nota de la duración. Los tiempos de espera comunes van de 15 minutos a 2 horas.
3. Iniciar una tarea e introducir datos sustanciales. Inicie sesión y comience a completar un formulario representativo, por ejemplo, un flujo de registro o compra con varios campos. Introduzca texto en los campos de texto, haga selecciones y avance por cualquier paso del asistente. No envíe el formulario.
4. Provocar la expiración de la sesión. Espere a que se produzca el tiempo de espera natural o, si tiene acceso de desarrollo, haga expirar artificialmente la sesión invalidando la cookie de sesión en las herramientas de desarrollo del navegador (pestaña Application > Cookies > eliminar la cookie de sesión) o expirando directamente la sesión en el servidor.
5. Observar el aviso de re-autenticación. Compruebe si el sitio le pide que vuelva a autenticarse (cumplimiento) o simplemente le redirige a una página de inicio de sesión sin aviso (un problema de usabilidad relacionado, aunque 2.2.5 se centra en la preservación de datos, no en el aviso en sí). Intente volver a iniciar sesión.
6. Verificar la preservación de datos después de iniciar sesión. Tras re-autenticarse correctamente, observe a dónde se le redirige y si sus datos introducidos previamente están intactos. Si se le envía a la página de inicio y/o sus datos de formulario han desaparecido, esto es un incumplimiento de 2.2.5.
7. Probar con tecnologías de apoyo. Repita la secuencia de pruebas anterior utilizando NVDA con Firefox, JAWS con Chrome y VoiceOver con Safari para asegurarse de que el aviso de re-autenticación es accesible para las personas usuarias de lectores de pantalla y de que el estado restaurado de la página se anuncia correctamente. Una persona vidente puede reconocer visualmente los datos restaurados; una persona usuaria de lector de pantalla necesita que el foco se sitúe correctamente y que el contenido restaurado esté en el orden de lectura.
8. Probar la navegación solo con teclado. Asegúrese de que todo el proceso de re-autenticación —desde el aviso de expiración de sesión hasta volver a iniciar sesión y regresar a la tarea preservada— se puede completar utilizando solo el teclado, sin requerir ratón.
9. Probar con simulaciones de tiempos de espera extendidos. Si es posible, reduzca el tiempo de espera de sesión a 1–2 minutos en un entorno de desarrollo y ejecute pruebas de recorrido completo de la persona usuaria para hacer el ciclo de pruebas más rápido y repetible.

Cómo corregir

Formulario de inicio de sesión simple con tiempo de espera de sesión: incorrecto

<!-- BAD: Session expires silently. On re-login, user is sent to homepage.
     All entered data in the checkout form is lost. -->
<form action='/checkout' method='POST' id='checkout-form'>
  <input type='text' name='full_name' placeholder='Full Name' />
  <input type='text' name='address' placeholder='Address' />
  <button type='submit'>Place Order</button>
</form>

<!-- Server-side: session expires after 10 minutes of inactivity.
     No state saved. POST redirect on login goes to /dashboard. -->

Formulario de inicio de sesión simple con tiempo de espera de sesión: correcto

<!-- GOOD: Before session expires, form state is saved server-side
     (or to sessionStorage as a fallback). After re-auth, the user
     is redirected back to the checkout page with data restored. -->

<!-- 1. JavaScript saves form state periodically to the server -->
<script>
  function saveFormState() {
    const formData = new FormData(document.getElementById('checkout-form'));
    const data = Object.fromEntries(formData.entries());
    // Save to server-side session keyed to authenticated user identity
    fetch('/api/save-draft', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ formId: 'checkout', data })
    });
  }
  // Auto-save every 60 seconds and on input change
  setInterval(saveFormState, 60000);
  document.getElementById('checkout-form')
    .addEventListener('input', saveFormState);
</script>

<!-- 2. On the server: when user re-authenticates,
     redirect to /checkout?restore=true
     which reloads saved draft data into the form -->
<form action='/checkout' method='POST' id='checkout-form'>
  <!-- Form fields are pre-populated from saved draft -->
  <input type='text' name='full_name' value='[restored value]'
         aria-label='Full Name' />
  <input type='text' name='address' value='[restored value]'
         aria-label='Address' />
  <button type='submit'>Place Order</button>
</form>

Asistente de varios pasos que pierde el progreso: incorrecto

<!-- BAD: Multi-step form uses only client-side state.
     Session expiry wipes wizard progress completely.
     Re-login sends user to step 1 with no data. -->

<div id='wizard'>
  <div class='step active' id='step-3'>
    <h2>Step 3 of 5: Employment History</h2>
    <textarea name='employment_history'>Typed content here...</textarea>
  </div>
</div>

<script>
  // State is only in JavaScript variables — lost on session expiry
  let wizardState = { step: 3, data: {} };
</script>

Asistente de varios pasos que pierde el progreso: correcto

<!-- GOOD: Wizard state is persisted server-side at each step
     and linked to the user's account. On re-authentication,
     the server restores the user to their last saved step
     with all data intact. A visible confirmation is shown. -->

<div id='wizard'>
  <div class='step active' id='step-3'
       aria-live='polite' aria-label='Step 3 of 5: Employment History'>
    <p role='status'>
      Your progress has been restored from your last session.
    </p>
    <h2>Step 3 of 5: Employment History</h2>
    <!-- Data is pre-populated from server-side draft -->
    <textarea name='employment_history'
              aria-label='Describe your employment history'>
      Previously entered content restored here...
    </textarea>
    <!-- Wizard nav saves progress before moving to next step -->
    <button type='button' onclick='saveAndProceed()'>Next Step</button>
  </div>
</div>

<script>
  async function saveAndProceed() {
    await fetch('/api/wizard/save', {
      method: 'POST',
      body: JSON.stringify({ step: 3, data: collectStepData() }),
      headers: { 'Content-Type': 'application/json' }
    });
    goToStep(4);
  }
</script>

Aviso de expiración de sesión sin preservación de datos: incorrecto

<!-- BAD: Site shows a countdown warning but does not save data.
     If the user misses the warning (e.g., screen reader user
     focused elsewhere), they lose all their work. -->
<div id='timeout-warning' style='display:none'>
  <p>Your session will expire in 2 minutes. <a href='/extend'>Extend</a></p>
</div>

Aviso de expiración de sesión sin preservación de datos: correcto

<!-- GOOD: Warning uses aria-live so screen readers announce it.
     Data is saved server-side regardless of whether the user
     extends the session — so re-auth always restores state. -->
<div id='timeout-warning'
     role='alertdialog'
     aria-live='assertive'
     aria-labelledby='warning-title'
     aria-describedby='warning-desc'
     hidden>
  <h2 id='warning-title'>Session Expiring Soon</h2>
  <p id='warning-desc'>
    Your session will expire in 2 minutes. Your work has been
    saved automatically. You can extend your session or log in
    again to continue exactly where you left off.
  </p>
  <button onclick='extendSession()'>Extend Session</button>
  <button onclick='dismissWarning()'>Dismiss</button>
</div>

Errores comunes

• Redirigir a la página de inicio después de la re-autenticación en lugar de a la página original: El patrón de fallo más común. Después de iniciar sesión, la aplicación envía a la persona usuaria a /dashboard o / en lugar de a la URL en la que estaba cuando su sesión expiró, obligándola a volver a su tarea manualmente, y sus datos ya se han perdido.
• Almacenar el estado del formulario solo en memoria JavaScript o en el estado de componentes React/Vue: El estado del framework del lado del cliente no sobrevive a una recarga de página provocada por una redirección de expiración de sesión a la página de inicio de sesión. El estado debe persistirse en el servidor o en un mecanismo de almacenamiento (por ejemplo, localStorage) que se restaure de forma fiable al regresar.
• Guardar una «URL de retorno» pero no los datos del formulario: Algunas implementaciones almacenan la URL a la que redirigir después de iniciar sesión, pero no guardan los valores reales de los campos del formulario. La persona usuaria llega a la página correcta pero con los campos vacíos, lo que sigue incumpliendo 2.2.5.
• Guardar automáticamente en sessionStorage, que se borra cuando se cierra la pestaña: Si la expiración de la sesión hace que la pestaña del navegador navegue a otra página (por ejemplo, redirigir a inicio de sesión), sessionStorage se borra. Use localStorage con un espacio de nombres asociado a la persona usuaria o, preferiblemente, almacenamiento de borradores en el servidor.
• No probar con campos de subida de archivos: Los campos de subida de archivos no pueden pre-rellenarse mediante HTML por motivos de seguridad. Si un formulario incluye una subida de archivo que se completó antes de la expiración de la sesión, la referencia al archivo se pierde. Las aplicaciones deben gestionar esto almacenando las referencias a los archivos subidos en el servidor y mostrando a la persona usuaria que su archivo sigue adjunto.
• Borrar los datos de borrador guardados inmediatamente tras la re-autenticación: Algunas implementaciones eliminan el borrador tan pronto como la persona usuaria inicia sesión, antes de verificar que realmente ha visto y confirmado los datos restaurados. El borrador debe preservarse hasta que la tarea se complete o se cancele explícitamente.
• No anunciar los datos restaurados a las personas usuarias de lectores de pantalla: Después de la re-autenticación y la redirección, las personas usuarias de lectores de pantalla necesitan una región aria-live o un anuncio enfocado que confirme que sus datos han sido restaurados y que pueden continuar donde lo dejaron. Sin esto, puede que no sepan que su trabajo se guardó.
• Tratar las sesiones basadas en AJAX de forma diferente a las sesiones basadas en páginas: Las aplicaciones de una sola página que utilizan autenticación basada en tokens (por ejemplo, caducidad de JWT) a menudo fallan silenciosamente en las llamadas a la API cuando el token expira sin dar a la persona usuaria la oportunidad de volver a autenticarse y reanudar. El mecanismo de re-autenticación debe ser igual de sólido para arquitecturas SPA.
• Usar <meta http-equiv='refresh'> para forzar el cierre de sesión sin guardar previamente los datos: Una meta refresh que se activa al tiempo de espera redirige inmediatamente a la persona usuaria sin ninguna preservación de estado en el servidor, lo que hace imposible la recuperación de datos. La gestión de sesión debe manejarse en la capa de aplicación con una persistencia adecuada del estado.
• Suponer que las sesiones cortas eliminan la necesidad de este criterio: Incluso un tiempo de espera de sesión de 5 minutos puede afectar a una persona que escribe despacio, a una persona con discapacidad cognitiva que relee las instrucciones o a alguien interrumpido por una persona cuidadora. La duración del tiempo de espera no cambia la obligación de preservar los datos a través de la re-autenticación.

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 el marco nacional para la accesibilidad digital y hace referencia a WCAG 2.2 como su estándar técnico de base. La circular exige conformidad para una amplia gama de entidades que operan en Turquía, incluidas instituciones y organismos públicos, plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales y proveedores de atención sanitaria privados, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas de transporte privado e instituciones educativas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

WCAG 2.2.5 Re-authenticating es un criterio de Nivel AAA, lo que significa que no se encuentra entre los requisitos mínimos legalmente exigidos en virtud de la Circular (que apunta a la conformidad de Nivel A y AA). Sin embargo, las organizaciones que busquen demostrar liderazgo en accesibilidad, atender a poblaciones de personas usuarias diversas, incluidas aquellas con discapacidad, o posicionarse como proveedores de servicios digitales de primer nivel deberían tratar los criterios de Nivel AAA —especialmente aquellos tan impactantes en la práctica como 2.2.5— como objetivos aspiracionales que vale la pena perseguir.

Ciertas categorías de entidades cubiertas tienen motivos particularmente sólidos para implementar 2.2.5. Los bancos y plataformas financieras a menudo requieren que las personas usuarias completen formularios extensos para solicitudes de préstamos, apertura de cuentas o productos de inversión, y sus tiempos de sesión cortos impulsados por la seguridad crean una tensión directa con las obligaciones de preservación de datos. Los hospitales y portales de atención sanitaria exponen a las personas pacientes a la pérdida de datos durante tareas críticas como la reserva de citas o la cumplimentación de cuestionarios de salud, lo que puede tener consecuencias reales para la continuidad de la atención. Las instituciones públicas que operan servicios de gobierno electrónico —como la presentación de impuestos, solicitudes de permisos o reclamaciones de prestaciones— atienden a ciudadanía con discapacidad que puede necesitar más tiempo para completar formularios gubernamentales complejos.

Aun cuando el cumplimiento de Nivel AAA no sea legalmente obligatorio, las organizaciones turcas deben ser conscientes de que los reguladores, las organizaciones de la sociedad civil y las personas defensoras de los derechos de las personas con discapacidad están examinando cada vez más la calidad y la exhaustividad de las implementaciones de accesibilidad digital. Documentar la conformidad con criterios de Nivel AAA como 2.2.5 refuerza la declaración de accesibilidad de una organización, reduce el riesgo de litigios y demuestra un compromiso genuino con el diseño inclusivo más allá del cumplimiento mínimo de casillas de verificación. Para las entidades con alcance internacional, especialmente aquellas que operan en mercados de la UE junto con Turquía, los criterios de Nivel AAA pueden cruzarse con los requisitos de la Ley Europea de Accesibilidad (EAA) y las implementaciones nacionales relacionadas.