WCAG 2.2.1: Tiempo ajustable

Qué Significa Esta Regla

WCAG 2.2.1 Ajustable por tiempo es un criterio de éxito de Nivel A bajo el Principio 2: Operable. Establece que, para cada límite de tiempo establecido por el contenido, al menos una de las siguientes condiciones debe cumplirse: la persona usuaria puede desactivar el límite de tiempo antes de encontrárselo; la persona usuaria puede ajustar el límite de tiempo dentro de un amplio rango (al menos diez veces la configuración predeterminada); o la persona usuaria puede extender el límite de tiempo con una acción sencilla —como pulsar una tecla o hacer clic en un botón— antes de que el tiempo expire, y se le advierte al menos con 20 segundos de antelación, con la opción de extenderlo al menos diez veces.

En términos prácticos, este criterio se aplica a cualquier interfaz web que imponga un cierre de sesión por inactividad, un carrusel que avanza automáticamente con diapositivas temporizadas, un formulario que se borra o se envía automáticamente, un temporizador de cuenta regresiva en una página de pago, un reproductor multimedia con subtítulos temporizados que no se pueden pausar, o cualquier otro mecanismo que limite el tiempo que una persona usuaria tiene para completar una tarea. Si tu página o aplicación establece un temporizador que, una vez expirado, elimina contenido, cierra la sesión de la persona usuaria o la lleva a un nuevo estado sin su consentimiento, debes ofrecer una forma de ajustar o extender ese límite.

El criterio también define tres excepciones importantes que pueden permitir que un límite de tiempo se mantenga sin los mecanismos de ajuste descritos anteriormente. Primero, la excepción de tiempo real: si el límite de tiempo es una parte necesaria de un evento en tiempo real (como una subasta en vivo o un examen en línea sincrónico), ajustar el tiempo invalidaría la actividad en sí misma y no es viable ninguna alternativa. Segundo, la excepción esencial: si el límite de tiempo es esencial y extenderlo invalidaría la actividad —por ejemplo, una prueba de habilidades cronometrada donde medir la velocidad de respuesta es el propósito. Tercero, la excepción de 20 horas: si el límite de tiempo es superior a 20 horas, se considera que la carga para las personas usuarias es mínima y no se requieren controles de ajuste.

Se considera un cumplimiento cuando una interacción limitada por tiempo proporciona un mecanismo claro —idealmente presentado antes de que se encuentre el límite— que permite a la persona usuaria desactivar, extender o ajustar la restricción de tiempo. Se considera un incumplimiento cuando el contenido expira automáticamente, redirige, cierra la sesión de la persona usuaria o avanza sin ofrecer ninguna de las tres opciones de ajuste anteriores, y ninguna de las tres excepciones aplica.

Por Qué Importa

Los límites de tiempo afectan de manera desproporcionada a las personas con discapacidad. Las personas usuarias que dependen de lectores de pantalla suelen navegar las páginas más lentamente que las personas videntes, porque escuchan el contenido de forma lineal y deben explorar interfaces desconocidas de manera secuencial. Las personas con discapacidades motoras —incluidas aquellas que usan dispositivos de acceso por pulsadores, software de seguimiento ocular, punteros bucales o software de control por voz— pueden tardar significativamente más en rellenar un campo de formulario, confirmar una compra o navegar al siguiente paso. Las personas con discapacidades cognitivas o de aprendizaje, incluidas la dislexia, condiciones de déficit de atención o dificultades de memoria, pueden necesitar tiempo adicional para leer, comprender y responder a las instrucciones. Las personas mayores también suelen necesitar más tiempo para las mismas tareas, y representan un segmento en rápido crecimiento de la población global de internet.

Considera un escenario concreto del mundo real: una persona con parálisis cerebral está completando una reserva de vuelo en el sitio web de una aerolínea turca. La sesión de pago expira automáticamente tras cinco minutos de inactividad. La persona usuaria, escribiendo lentamente con un dispositivo de puntero en la cabeza, ha introducido su nombre, número de pasaporte y datos de pago, y entonces la página se recarga, borrando todos los datos y devolviéndola a la página de inicio. No solo se ha perdido su esfuerzo, sino que su confianza en el sitio se ve afectada, y puede que no sea capaz de completar la compra en absoluto. Esto es una barrera directa a la participación en igualdad de condiciones en el comercio digital.

El impacto es más amplio que el de las personas usuarias individuales. Según la Organización Mundial de la Salud, aproximadamente 1.3 mil millones de personas en todo el mundo viven con alguna forma de discapacidad significativa. Solo en Turquía, las estadísticas oficiales de TÜİK indican que más de 8.5 millones de personas tienen una discapacidad que afecta las actividades diarias. Las interfaces con límites de tiempo excluyen una parte medible de la base potencial de personas usuarias de cualquier aplicación web.

Más allá de la accesibilidad, eliminar límites de tiempo arbitrarios o hacerlos ajustables también beneficia a personas usuarias en entornos de bajo ancho de banda, a personas con una discapacidad motora temporal (como un brazo roto) y a personas que simplemente son interrumpidas durante una tarea. Las mejoras de usabilidad son amplias y pueden reducir las tasas de abandono de formularios, aumentar las tasas de conversión en sitios de comercio electrónico y disminuir el volumen de solicitudes al servicio de atención a la clientela.

Reglas Relacionadas de Axe-core

WCAG 2.2.1 requiere pruebas manuales. Las herramientas automatizadas —incluidas axe-core, Lighthouse y motores similares— no pueden detectar de forma fiable infracciones relacionadas con el tiempo porque los límites de tiempo suelen implementarse en la lógica de sesión del lado del servidor, en JavaScript que se ejecuta de forma asíncrona o en integraciones de terceros. La herramienta no tiene forma de observar que una página expirará en cinco minutos, o que un carrusel avanzará sin la intervención de la persona usuaria, simplemente inspeccionando el DOM o ejecutando análisis estático. Las siguientes consideraciones explican qué deben evaluar manualmente las personas que realizan las pruebas.

• Cierres de sesión por inactividad (manual): Las personas que realizan las pruebas deben esperar o simular un cierre de sesión por inactividad para determinar si la página presenta una advertencia previa, ofrece una opción de extensión y proporciona al menos 20 segundos para que la persona usuaria responda. Ninguna regla automatizada puede determinar la duración de la sesión o si un cuadro de diálogo de advertencia aparece a tiempo sin esperar realmente a que se produzca el cierre.
• Carruseles y deslizadores que avanzan automáticamente (manual): Las personas que realizan las pruebas deben observar si los carruseles avanzan automáticamente y, en caso afirmativo, si hay un control de pausa o detención presente y accesible mediante teclado. Axe-core puede detectar algunos atributos ARIA faltantes en componentes de carrusel, pero no puede determinar si el avance temporizado en sí es ajustable.
• Formularios que se envían o se borran automáticamente (manual): Si un formulario se envía o borra su contenido tras un período de inactividad, una persona que realiza las pruebas debe identificar este comportamiento mediante la observación o la revisión del código. El DOM por sí solo no revela este comportamiento a un escáner automatizado.
• Temporizadores de cuenta regresiva en flujos transaccionales (manual): Las páginas de pago, los flujos de reserva de entradas y los entornos de examen incluyen con frecuencia temporizadores de cuenta regresiva. Determinar si estos temporizadores son esenciales (y por tanto están exentos) o si requieren un mecanismo de extensión es una decisión que requiere una revisión humana tanto de la implementación como del contexto de negocio.

Cómo Probar

1. Base de escaneo automatizado: Ejecuta axe DevTools o Lighthouse en la página para identificar cualquier infracción conocida de ARIA o de elementos interactivos que pueda agravar los problemas de tiempo. Ten en cuenta que estas herramientas no marcarán el límite de tiempo en sí, pero ayudan a establecer una base de otros problemas de accesibilidad. En Chrome DevTools, abre el panel Lighthouse, selecciona Accessibility y ejecuta la auditoría. En axe DevTools, activa la extensión del navegador, haz clic en Analyze y revisa los resultados: no aparecerá ninguna regla específica de tiempo, lo que confirma que se requieren pruebas manuales.
2. Identificar todos los límites de tiempo: Revisa el código fuente JavaScript de la página, las solicitudes de red y la configuración de sesión del lado del servidor para identificar cada límite de tiempo. Ubicaciones comunes incluyen llamadas a setTimeout y setInterval en JavaScript, configuraciones de expiración de sesión en frameworks de backend, valores de expiración de cookies y configuraciones de widgets de terceros como procesadores de pago o widgets de chat.
3. Probar la advertencia de cierre de sesión con NVDA + Firefox: Abre el sitio en Firefox con NVDA en ejecución. Navega por un formulario de varios pasos o una sección autenticada. Espera al cuadro de diálogo de advertencia de sesión (o al cierre de sesión en sí si no aparece ninguna advertencia). Verifica que NVDA anuncie la advertencia automáticamente —idealmente mediante una región en vivo— y que la persona usuaria pueda extender la sesión pulsando Enter o Space en un botón enfocado sin perder los datos del formulario.
4. Probar la advertencia de cierre de sesión con VoiceOver + Safari (macOS/iOS): Repite la prueba anterior en Safari con VoiceOver activado. Usa el rotor para navegar por los elementos interactivos y confirma que se anuncia la advertencia de cierre de sesión y que el control de extensión es accesible dentro de la ventana de 20 segundos.
5. Probar la advertencia de cierre de sesión con JAWS + Chrome: Repite la prueba con JAWS en Chrome. Confirma que el foco se mueve al cuadro de diálogo de advertencia, que JAWS lee el tiempo restante y la opción de extensión, y que al activar el botón de extensión la sesión se mantiene activa sin requerir una recarga de la página.
6. Probar solo con teclado (sin lector de pantalla): Desactiva el ratón y navega únicamente con Tab, Shift+Tab, Enter y Space. Confirma que cualquier cuadro de diálogo de advertencia es accesible mediante teclado, que el botón de extensión se puede enfocar y que el foco vuelve a la ubicación correcta en el formulario después de extender la sesión.
7. Probar el tiempo de carruseles y medios: Identifica cualquier carrusel que avance automáticamente. Navega hasta el carrusel usando Tab. Verifica que haya un botón de pausa o detención presente y accesible sin ratón. Actívalo y confirma que el avance se detiene. Si el carrusel se reanuda tras la interacción de la persona usuaria, confirma que no se reanuda automáticamente.
8. Verificar la aplicabilidad de las excepciones: Para cada límite de tiempo encontrado, determina si aplica la excepción de tiempo real, la esencial o la de 20 horas. Documenta tu razonamiento. Si ninguna de las excepciones aplica y no existe un mecanismo de ajuste, registra esto como un incumplimiento de WCAG 2.2.1.

Cómo Corregir

Cierre de sesión por inactividad sin advertencia — Incorrecto

<!-- Session expires silently after 5 minutes; page reloads with no warning -->
<script>
  setTimeout(function() {
    window.location.href = '/session-expired';
  }, 300000);
</script>

Cierre de sesión por inactividad con advertencia y extensión — Correcto

<!-- Warn user 60 seconds before expiry; offer extension; announce via live region -->
<div
  id='session-warning'
  role='alertdialog'
  aria-modal='true'
  aria-labelledby='warning-title'
  aria-describedby='warning-desc'
  hidden
>
  <h2 id='warning-title'>Your session is about to expire</h2>
  <p id='warning-desc'>
    Your session will expire in <span id='countdown'>60</span> seconds.
    Select "Stay logged in" to continue your session.
  </p>
  <button id='extend-btn' type='button'>Stay logged in</button>
  <button id='logout-btn' type='button'>Log out now</button>
</div>

<script>
  var SESSION_DURATION = 300000; // 5 minutes
  var WARNING_BEFORE   = 60000;  // warn 60 seconds before
  var sessionTimer, warningTimer, countdownInterval;

  function startSessionTimer() {
    warningTimer = setTimeout(showWarning, SESSION_DURATION - WARNING_BEFORE);
    sessionTimer = setTimeout(expireSession, SESSION_DURATION);
  }

  function showWarning() {
    var dialog = document.getElementById('session-warning');
    dialog.hidden = false;
    document.getElementById('extend-btn').focus(); // move focus to dialog
    var seconds = 60;
    countdownInterval = setInterval(function() {
      seconds--;
      document.getElementById('countdown').textContent = seconds;
      if (seconds <= 0) clearInterval(countdownInterval);
    }, 1000);
  }

  function extendSession() {
    clearTimeout(sessionTimer);
    clearTimeout(warningTimer);
    clearInterval(countdownInterval);
    document.getElementById('session-warning').hidden = true;
    startSessionTimer();
    // Return focus to last active element
  }

  function expireSession() {
    window.location.href = '/session-expired';
  }

  document.getElementById('extend-btn').addEventListener('click', extendSession);
  document.getElementById('logout-btn').addEventListener('click', expireSession);
  startSessionTimer();
</script>

Carrusel que avanza automáticamente sin controles — Incorrecto

<!-- Slides advance every 4 seconds; no pause control; no keyboard access -->
<div class='carousel'>
  <div class='slide active'>Slide 1 content</div>
  <div class='slide'>Slide 2 content</div>
  <div class='slide'>Slide 3 content</div>
</div>

Carrusel que avanza automáticamente con control de pausa — Correcto

<!-- Pause button stops auto-advance; button label updates to reflect state -->
<section aria-roledescription='carousel' aria-label='Featured announcements'>
  <div aria-live='off' aria-atomic='true'>
    <div class='slide active' role='group' aria-roledescription='slide' aria-label='Slide 1 of 3'>
      Slide 1 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 2 of 3'>
      Slide 2 content
    </div>
    <div class='slide' role='group' aria-roledescription='slide' aria-label='Slide 3 of 3'>
      Slide 3 content
    </div>
  </div>
  <button id='carousel-pause' type='button' aria-pressed='false'>
    Pause slideshow
  </button>
</section>

<script>
  var paused = false;
  var btn = document.getElementById('carousel-pause');
  btn.addEventListener('click', function() {
    paused = !paused;
    btn.setAttribute('aria-pressed', paused.toString());
    btn.textContent = paused ? 'Play slideshow' : 'Pause slideshow';
    // toggle the carousel's auto-advance logic accordingly
  });
</script>

Cuenta regresiva de pago con tiempo limitado sin extensión — Incorrecto

<!-- 10-minute checkout lock; no extension offered; not an essential exception -->
<p>Your items are reserved for: <span id='timer'>10:00</span></p>
<!-- Timer expires, cart is cleared silently -->

Cuenta regresiva de pago con tiempo limitado con opción de extensión — Correcto

<!-- Warn before expiry and offer a one-click extension -->
<p>
  Your items are reserved for:
  <span id='timer' aria-live='polite' aria-atomic='true'>10:00</span>
</p>
<div id='extend-notice' hidden role='alert'>
  <p>Your reservation expires in 2 minutes.</p>
  <button type='button' id='extend-checkout'>Give me more time</button>
</div>
<!--
  When timer reaches 2:00, reveal #extend-notice.
  Clicking the button resets the reservation timer via an API call.
  aria-live='alert' ensures screen readers announce the warning immediately.
-->

Errores Comunes

• Mostrar una advertencia de cierre de sesión sin gestión del foco del teclado: El cuadro de diálogo de advertencia aparece visualmente pero el foco nunca se mueve a él, por lo que las personas usuarias que solo usan teclado y las que usan lectores de pantalla nunca descubren que pueden extender la sesión antes de que expire.
• Proporcionar menos de 20 segundos para responder a una advertencia de cierre de sesión: Mostrar una alerta de "La sesión está expirando" solo 10 segundos antes del cierre de sesión no cumple el criterio, que requiere que haya al menos 20 segundos disponibles para la acción de extensión.
• Usar role='alert' en un cuadro de diálogo de tiempo de espera que requiere interacción: El rol alert es para anuncios de solo lectura; un cuadro de diálogo que requiere la entrada de la persona usuaria debe usar role='alertdialog' con aria-modal='true' y aria-labelledby para que los lectores de pantalla lo traten como un modal que requiere respuesta.
• Alegar la excepción esencial para un temporizador estándar de carrito de comercio electrónico: Reservar artículos en un carrito de compra durante 10 minutos es una conveniencia comercial, no una actividad verdaderamente esencial donde el propósito sea medir la velocidad. Aplicar aquí la excepción esencial es incorrecto; se requiere un mecanismo de extensión.
• Hacer que un carrusel avance automáticamente sin un botón de pausa visible y accesible mediante teclado: Añadir un botón de pausa que solo sea visible al pasar el cursor, o que esté ausente del orden de tabulación, no cumple el criterio. El control debe ser accesible sin un dispositivo apuntador.
• Reiniciar el contador de tiempo de espera ante cualquier movimiento del ratón pero no ante eventos de teclado: Un JavaScript que extiende el temporizador de inactividad en eventos de mousemove pero ignora eventos de keydown o focus hará que las sesiones expiren silenciosamente para las personas usuarias que solo usan teclado y que están trabajando activamente en la página.
• Extender la sesión mediante una recarga completa de la página: Cuando una persona hace clic en "Permanecer conectada", recargar la página borra cualquier dato que hubiera introducido en los formularios. La extensión debe producirse mediante una llamada a una API o una actualización de la cookie en segundo plano, preservando el estado del DOM.
• Usar valores de setTimeout que no son configurables ni están expuestos a la persona usuaria: Codificar de forma rígida una duración de sesión de cinco minutos sin ningún control en la interfaz para que la persona usuaria pueda elegir una duración mayor infringe el criterio, a menos que una de las tres opciones de ajuste (desactivar, ajustar o extender) esté disponible.
• No probar el flujo de tiempo de espera con tecnologías de apoyo reales antes del lanzamiento: Las personas desarrolladoras que solo prueban con ratón pueden no darse cuenta de que el cuadro de diálogo de advertencia es inaccesible para quienes usan lectores de pantalla, porque las pruebas con visión no revelan fallos en la gestión del foco.
• Suponer que los widgets incrustados de terceros cumplen automáticamente: Los procesadores de pago, widgets de chat en vivo y motores de reserva incrustados mediante iframes o scripts suelen imponer sus propios límites de tiempo. La responsabilidad del cumplimiento de WCAG de la página completa —incluido el contenido incrustado que controlas— recae en la persona propietaria de la página.

Relación con las Normativas 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 requisitos obligatorios de accesibilidad web alineados con WCAG 2.2 Nivel AA para una amplia gama de entidades públicas y privadas que operan servicios digitales en Turquía. WCAG 2.2.1 Ajustable por tiempo es un criterio de Nivel A, lo que significa que se sitúa en la capa fundamental de conformidad: está entre los primeros requisitos que las entidades cubiertas deben satisfacer.

Según la circular, las instituciones y organismos públicos —incluidos ministerios, municipios, universidades y empresas de propiedad estatal— deben lograr la conformidad total en el plazo de un año a partir de la fecha de publicación de la circular. Las entidades del sector privado cubiertas por la regulación disponen de un plazo de dos años para cumplir. El alcance del sector privado es explícitamente amplio: abarca plataformas de comercio electrónico, bancos e instituciones financieras, hospitales privados y proveedores de servicios de salud, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas privadas de transporte de pasajeros y escuelas privadas que operan bajo una autorización del Ministerio de Educación Nacional (MoNE).

Para las organizaciones de estas categorías, un incumplimiento de WCAG 2.2.1 no es simplemente una carencia de buenas prácticas: es una no conformidad legal que puede atraer el escrutinio regulatorio, quejas a través de canales oficiales y daños reputacionales. Considera los flujos de negocio específicos con más probabilidad de desencadenar esta infracción: un proceso de pago de comercio electrónico con una reserva de carrito cronometrada, una sesión de banca en línea que expira silenciosamente mientras una clienta rellena un formulario de pago, un sistema de citas hospitalarias que se agota antes de que una persona con discapacidad motora pueda completar su registro, o un portal de autoservicio de un proveedor de telecomunicaciones que cierra automáticamente la sesión de las personas usuarias en medio de un flujo de gestión de contrato. Cada uno de estos es un escenario de fallo plausible dentro de un tipo de entidad que se menciona explícitamente en la circular.

Las organizaciones deben tratar el cumplimiento de WCAG 2.2.1 no como una casilla técnica que marcar, sino como un requisito de diseño que debe abordarse a nivel de arquitectura —en las políticas de gestión de sesiones, los requisitos de adquisición de widgets de terceros y los estándares de componentes de interfaz— en lugar de añadirse a posteriori como una idea tardía. Los programas de auditoría deben incluir pruebas manuales de todas las interacciones con tiempo limitado, no solo escaneos automatizados, precisamente porque las herramientas automatizadas no pueden detectar esta clase de infracción sin observación humana.