WCAG 2.2.6: Tiempos de espera

Qué significa esta regla

WCAG 2.2.6 Timeouts (Nivel AAA) requiere que se advierta a las personas usuarias sobre la duración de cualquier inactividad que pueda causar pérdida de datos, a menos que los datos se conserven durante más de 20 horas de inactividad del usuario. En términos prácticos, esto significa que si tu aplicación web o servicio puede perder los datos de una persona usuaria —como entradas en un formulario, un carrito de compra o una transacción en curso— debido a que la persona ha estado inactiva durante un período de tiempo, debes informar a las personas usuarias exactamente de cuánto tiempo disponen antes de que esos datos se pierdan.

El criterio se aplica a cualquier situación en la que un tiempo de espera dé lugar a pérdida de datos. Ejemplos comunes incluyen la caducidad de sesión en portales bancarios o gubernamentales que borra los datos del formulario, carritos de compra que se vacían tras un período de inactividad, asistentes o formularios de varios pasos que se reinician cuando caduca una cookie de sesión y sistemas de exámenes o reservas en línea que descartan respuestas parciales. El desencadenante clave es la combinación de inactividad (no un límite de tiempo estricto para completar una tarea, que está cubierto por 2.2.1) y la consecuencia de pérdida de datos.

Qué se considera un cumplimiento: Una página cumple con 2.2.6 si informa claramente a las personas usuarias al inicio de una sesión —o antes de que comiencen a introducir datos— de la duración específica de inactividad que dará lugar a pérdida de datos. Alternativamente, una página cumple si no puede producirse ninguna pérdida de datos independientemente de cuánto tiempo permanezca inactiva la persona usuaria (por ejemplo, porque el servidor conserva todos los datos del formulario durante más de 20 horas, o indefinidamente). Mostrar una advertencia solo después de que la sesión ya haya caducado no satisface el criterio.

Qué se considera un incumplimiento: Una página incumple si pierde datos de la persona usuaria de forma silenciosa tras un período de inactividad sin informar nunca a la persona de este riesgo. También incumple si existe una advertencia pero se presenta solo en el momento de la pérdida de datos (demasiado tarde para actuar), o si la advertencia es vaga —por ejemplo, indicando "su sesión puede caducar" sin especificar la duración real de inactividad que desencadena el tiempo de espera.

Excepciones oficiales: El criterio exime explícitamente las situaciones en las que los datos se conservan durante más de 20 horas de inactividad. El umbral de 20 horas se eligió para acomodar a las personas usuarias que comienzan una tarea un día y la reanudan al siguiente. Si tu sistema almacena de forma fiable todos los datos introducidos en el servidor durante al menos 20 horas sin que se requiera ninguna acción por parte de la persona usuaria, no estás obligado a mostrar una advertencia. Además, este criterio no se aplica a los tiempos de espera que sean esenciales para la seguridad —por ejemplo, un requisito estricto por ley o regulación de que una sesión debe terminar tras un período fijo independientemente de la acción de la persona usuaria. En tales casos, el criterio sigue fomentando la divulgación, pero reconoce la restricción legal.

Por qué es importante

Los tiempos de espera sin una advertencia adecuada afectan de forma desproporcionada a las personas con discapacidades cognitivas, discapacidades motoras y a quienes son ciegas o tienen baja visión. Las personas con discapacidades cognitivas como dislexia, TDAH o lesión cerebral traumática pueden necesitar mucho más tiempo para leer instrucciones, redactar texto o revisar información antes de enviar un formulario. Si una sesión caduca silenciosamente mientras aún están trabajando, pierden todo su esfuerzo y deben empezar de nuevo, una experiencia profundamente desalentadora que puede hacer que abandonen la tarea por completo.

Las personas con discapacidades motoras que dependen de acceso por pulsadores, dispositivos de seguimiento ocular u otros métodos de entrada alternativos interactúan con las interfaces a un ritmo mucho más lento que una persona usuaria de ratón. Completar un formulario largo de reclamación de seguro o una solicitud gubernamental de varias páginas puede llevarles muchas veces más tiempo del que asume el tiempo de espera de sesión predeterminado. Sin conocer la cuenta atrás, no tienen oportunidad de actuar —como guardar el progreso o solicitar una extensión— antes de que sus datos desaparezcan.

Las personas usuarias de lectores de pantalla también se enfrentan a un desafío añadido: navegar por formularios complejos lleva más tiempo cuando cada campo debe leerse en voz alta y confirmarse con el teclado. Una sesión que caduca mientras una persona usuaria aún está trabajando metódicamente en un formulario largo no es simplemente una molestia: puede representar horas de esfuerzo perdido y una barrera significativa para acceder a servicios esenciales.

Considera este escenario del mundo real: una persona con esclerosis múltiple está solicitando una prestación por discapacidad a través de un portal gubernamental. El formulario tiene 12 secciones y requiere subir documentos justificativos. La sesión caduca tras 15 minutos de inactividad, pero la persona se detuvo a mitad de la sección 7 para ir a otra habitación a buscar un documento. Al regresar, todos los datos se han borrado y debe comenzar de nuevo, sin ninguna advertencia previa de que esto ocurriría. En virtud de 2.2.6, el portal estaría obligado a informar a la persona usuaria desde el principio de que la inactividad durante más de 15 minutos dará lugar a pérdida de datos, permitiéndole planificar en consecuencia.

Más allá de la accesibilidad, divulgar de forma proactiva el comportamiento de los tiempos de espera mejora la experiencia de uso para todas las personas y reduce las tasas de abandono en flujos de conversión de alto valor como el pago, el registro y los formularios de solicitud. También genera confianza, ya que las personas usuarias no se quedan preguntándose por qué desaparecieron sus datos.

Reglas relacionadas de Axe-core

WCAG 2.2.6 requiere pruebas manuales. No existe una regla automatizada de axe-core que pueda detectar esta infracción, y entender por qué es importante tanto para quienes realizan pruebas como para las personas desarrolladoras.

• Se requieren pruebas manuales — Divulgación del tiempo de espera de sesión: Las herramientas automatizadas como axe-core pueden analizar el DOM en busca de la presencia o ausencia de elementos específicos, atributos y patrones de texto, pero no pueden determinar si una aplicación web perderá datos de la persona usuaria tras un período de inactividad. El comportamiento del tiempo de espera suele estar gobernado por la configuración de sesión del lado del servidor (por ejemplo, un TTL de sesión en PHP o Node.js), y la divulgación —si existe— puede aparecer en un texto de incorporación, un cuadro de diálogo modal, una página de ayuda o incluso en una sección de términos de servicio. Ningún análisis estático del DOM puede correlacionar de forma fiable un fragmento de texto informativo con el comportamiento real del tiempo de espera del lado del servidor. Una herramienta no puede saber si una frase como "Por su seguridad, las sesiones caducan después de 15 minutos" es precisa, si se aplica a los datos de la página actual o si está situada lo suficientemente temprano en el recorrido de la persona usuaria como para ser útil. Solo una persona que realiza pruebas, capaz de interactuar con la aplicación, observar su comportamiento a lo largo del tiempo y evaluar la exhaustividad y el momento de cualquier divulgación, puede determinar el cumplimiento.
• Se requieren pruebas manuales — Verificación de la preservación de datos: Axe-core tampoco puede verificar la excepción de 20 horas. Si los datos se almacenan realmente en el servidor durante más de 20 horas —y, por tanto, si es necesaria alguna divulgación— depende por completo de la lógica de backend que es invisible para una herramienta de análisis basada en el navegador. Quienes realizan pruebas deben revisar la configuración del servidor, hablar con las personas desarrolladoras o hacer pruebas empíricas dejando un formulario parcialmente completado durante un período prolongado y observando si los datos persisten.

Cómo hacer las pruebas

1. Preanálisis automatizado: Ejecuta axe DevTools o Lighthouse en la página que contiene el formulario, el flujo de pago u otra interfaz de introducción de datos. Aunque ninguna de las dos herramientas señalará directamente una infracción de 2.2.6, utiliza este paso para identificar cualquier región ARIA en vivo relacionada con tiempos de espera o componentes de diálogo que puedan formar parte del mecanismo de advertencia, y verifica que ellos mismos sean accesibles (roles correctos, etiquetas, gestión del foco).
2. Identificar el comportamiento del tiempo de espera: Habla con el equipo de desarrollo o revisa la configuración del lado del servidor para determinar la duración del tiempo de espera por inactividad de la sesión. Las ubicaciones comunes incluyen archivos de configuración del servidor web, ajustes de middleware de sesión de la aplicación y documentación del proveedor de autenticación. Registra la duración exacta en minutos.
3. Comprobar la divulgación previa: Carga la página desde cero y lee todo el contenido presentado a la persona usuaria antes de que comience cualquier introducción de datos. Busca una declaración clara —en el cuerpo de la página, un párrafo introductorio, un banner o un modal— que especifique la duración exacta del tiempo de espera por inactividad y que indique que los datos se perderán si la persona usuaria permanece inactiva durante ese período. La divulgación debe indicar la duración explícitamente (por ejemplo, "15 minutos"), no de forma vaga (por ejemplo, "un corto período de tiempo").
4. Probar con un lector de pantalla: Usando NVDA con Firefox, VoiceOver con Safari o JAWS con Chrome, navega por la página desde el principio. Confirma que cualquier divulgación del tiempo de espera sea alcanzable y leída en voz alta por el lector de pantalla sin requerir que la persona usuaria la busque activamente. Si la divulgación está en un banner visualmente destacado, verifica que esté en el orden de lectura antes del primer campo del formulario.
5. Simular inactividad: Comienza a rellenar el formulario. Luego deja de interactuar con la página durante un tiempo ligeramente inferior al período de tiempo de espera y observa qué ocurre. Después repite, esperando hasta que el período de tiempo de espera haya transcurrido. Registra si se pierden datos, si se muestra una advertencia antes de que se produzca la pérdida de datos y si esa advertencia se comunicó antes de que comenzara la sesión.
6. Probar la excepción de 20 horas: Si el equipo afirma que los datos se conservan durante más de 20 horas, verifica esto empíricamente completando parcialmente un formulario, esperando al menos 20 horas y volviendo a la página para confirmar que los datos siguen presentes. Alternativamente, revisa la configuración del almacén de sesiones del lado del servidor con el equipo de desarrollo.
7. Pruebas de teclado y foco: Si aparece un cuadro de diálogo o notificación de advertencia de tiempo de espera, verifica usando solo el teclado que recibe el foco automáticamente, que su contenido es completamente legible y que la persona usuaria puede descartarlo o actuar (por ejemplo, extender la sesión) sin usar el ratón.

Cómo corregirlo

Sesión con pérdida silenciosa de datos — Incorrecto

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

Sesión con pérdida silenciosa de datos — Correcto

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

Sesión de pago con advertencia vaga — Incorrecto

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Sesión de pago con advertencia vaga — Correcto

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

Datos conservados en el servidor durante más de 20 horas — Correcto (aplica la excepción)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

Errores comunes

• Mostrar la advertencia de tiempo de espera solo dentro de la consola del navegador o en una entrada de registro del servidor que es invisible para las personas usuarias finales: la advertencia debe presentarse en la interfaz de usuario, en un lugar que la persona usuaria encuentre antes de que se produzca la pérdida de datos.
• Colocar la divulgación en un pie de página, una política de privacidad o una página de términos de servicio que es poco probable que las personas usuarias lean antes de comenzar a introducir datos, en lugar de directamente en el formulario o inmediatamente antes de este.
• Usar un cuadro de diálogo modal para advertir a las personas usuarias de una caducidad inminente de la sesión pero no mover el foco del teclado al cuadro de diálogo: las personas usuarias de teclado y lector de pantalla pueden no llegar a ser conscientes de que la advertencia ha aparecido.
• Indicar una duración de sesión (por ejemplo, "su sesión dura 30 minutos") en lugar de un tiempo de espera por inactividad (por ejemplo, "después de 15 minutos de inactividad, sus datos se perderán"): son conceptos diferentes, y solo la pérdida de datos desencadenada por la inactividad está gobernada por 2.2.6.
• Suponer que, porque existe un modal de advertencia de tiempo de espera para personas videntes, el criterio está satisfecho: si el modal no es accesible mediante teclado, carece de un nombre accesible o no se anuncia mediante regiones ARIA en vivo o gestión del foco, las personas usuarias de lectores de pantalla no recibirán la advertencia.
• Configurar el tiempo de espera de sesión del lado del servidor en 25 horas y concluir que no se necesita divulgación, sin verificar que el estado del lado del navegador o a nivel de aplicación (por ejemplo, un almacén de Redux o localStorage) no se borre antes: el tiempo de espera efectivo es el del mecanismo que pierde los datos primero.
• Divulgar la duración del tiempo de espera en una información emergente (tooltip) que solo se activa al pasar el cursor: las personas que dependen de la navegación por teclado o de dispositivos táctiles pueden no llegar nunca a ver la divulgación.
• Confiar en una advertencia genérica del CMS o del framework que dice "sesión caducada" y que se muestra después de que la pérdida de datos ya se haya producido, en lugar de informar de forma proactiva a las personas usuarias antes de que comiencen a introducir datos.
• No tener en cuenta a las personas usuarias que abren el formulario en una pestaña en segundo plano: si el temporizador de sesión se ejecuta mientras la pestaña está inactiva, los datos pueden perderse antes de que la persona usuaria haya tenido oportunidad de interactuar con el formulario. Esto es especialmente problemático en navegadores móviles que suspenden agresivamente las pestañas en segundo plano.
• Omitir la advertencia en las versiones móviles o en contextos de aplicaciones web progresivas (PWA) mientras se muestra en la versión de escritorio, creando una experiencia inconsistente que incumple 2.2.6 para una parte significativa de las personas usuarias.

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 vinculantes de accesibilidad web para una amplia gama de entidades públicas y privadas que operan en Turquía. La circular exige el cumplimiento de WCAG 2.2 como estándar técnico, requiriendo que las entidades cubiertas alcancen como mínimo la conformidad de Nivel AA. WCAG 2.2.6 Timeouts es un criterio de Nivel AAA y, por lo tanto, no está directamente exigido por los requisitos básicos de la circular. Sin embargo, el alcance y la intención de la circular crean razones prácticas de peso para que las entidades cubiertas persigan la conformidad AAA en criterios como 2.2.6.

Las entidades cubiertas por la Circular Presidencial 2025/10 incluyen instituciones y organismos públicos, plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de atención sanitaria, operadores de telecomunicaciones con más de 200,000 abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Muchos de estos sectores operan portales en línea que implican precisamente los tipos de flujos de introducción de datos que 2.2.6 está diseñado para proteger: solicitudes de préstamos, formularios de admisión de pacientes, sistemas de reserva de billetes, solicitudes de matrícula y reclamaciones de prestaciones gubernamentales.

Para los bancos y las plataformas de comercio electrónico en particular, los tiempos de espera de sesión son una medida de seguridad habitual, y la interacción entre los requisitos de seguridad y las obligaciones de accesibilidad es directamente relevante. Aunque un banco pueda tener la obligación regulatoria de terminar las sesiones inactivas tras un período fijo, implementar WCAG 2.2.6 divulgando la duración del tiempo de espera por adelantado no entra en conflicto con ese requisito de seguridad: lo complementa. Las personas usuarias son conscientes de la limitación sin que el banco tenga que debilitar su postura de seguridad de sesión.

Los proveedores de atención sanitaria y los hospitales cubiertos por la circular gestionan algunas de las tareas de introducción de datos de mayor riesgo imaginables: formularios de historial médico, solicitudes de autorización previa y sistemas de programación de citas. Las personas pacientes con discapacidades cognitivas o motoras que pierden sus datos a mitad de un formulario en estos contextos se enfrentan no solo a la frustración, sino a posibles retrasos en la recepción de atención. Implementar 2.2.6 en estos entornos es una expresión directa del mandato de servicio inclusivo que sustenta la circular.

Aunque el Nivel AAA no es un requisito legal, alcanzarlo en criterios como 2.2.6 —que requieren un esfuerzo de implementación relativamente bajo (añadir una única declaración de divulgación precisa a un formulario) y al mismo tiempo proporcionan un beneficio significativo a grupos de personas usuarias vulnerables— representa una práctica de accesibilidad de primer nivel. Las organizaciones que buscan demostrar su compromiso con la inclusión digital en el mercado turco, o aquellas que anticipan una regulación más estricta en el futuro, se benefician al tratar 2.2.6 como un objetivo práctico de implementación más que como una aspiración opcional.